(04-10-2014 07:53 PM)Han Wrote:  

(04-10-2014 03:06 PM)orcinus Wrote:  Tiny tweak to Miguel's fork:
https://dl.dropboxusercontent.com/u/1702513/HP_ELEMENTS_colorfix.zip

The TEXTOUT_P's responsible for text within the tiles didn't have a color specified, so they defaulted to system default.
Which changes with the theme, resulting in white text on light background when using the Dark color theme.

I've hardcoded #000000 in those places.

Some suggestions for this version:

1. Make the element selection a local variable but declared outside of any function so that when a user re-runs the program, the previously selected element is the default selection. Or, have the default selection already be set to 1 (Hydrogen).
2. The selected element should be more visible. The 2-pixel wide line used to draw the box is very hard to read. Instead, use FILLPOLY with an alpha blending that darkens the background color and changes the font to white. It makes the selection stand out and much easier to see.
3. The keyboard handler is very inefficient and makes it so that the user must have a key held down at exactly the moment the program executes the ISKEYDOWN() command. Since you are using WAIT without any arguments, it will wait a set amount of time (1 minute ?) before checking the status of the key. So a user could press something and nothing will happen if the code is still inside the internal WAIT loop. Instead, use WAIT(-1) and parse the output there. Here's a skeleton on how to create a keyboard and mouse handler with WAIT():

Code:


EXPORT KMINPUT()
BEGIN
  LOCAL run:=1, key;

  // change run to 0 to exit the while loop
  key:=WAIT(-1);
  CASE
    IF TYPE(key)==6 THEN
      // we have touchscreen events
      CASE
        IF key(1)==0 THEN kmMouseDown(); END;
        IF key(1)==1 THEN kmMouseUp(); END;
        // ... more mouse events
        IF key(1)==7 THEN kmMouseLongClick(); END;

        kmMouseEvent(); // default handler
      END;
    END; // end of touch events

    // at this point, all touch events were handled due to the
    // TYPE(key)==6 check; so only key-presses are left
    // and if a touch event occurred, these tests below are
    // never reached

    IF key==0 THEN kmDoAppsKey(); END;
    // ... more key definitions here
    IF key==50 THEN kmDoPlusKey(); END;

    kmOtherEvents(); // handle all remaining undefined keys
  END;

END;

Encase the code above inside a loop environment and you will always trap a user's keypress. This is only good for when you expect users to not press any keys during the execution of subroutines, of course, although it should still work since there is (should be?) a key buffer. You can additionally add in an ISKEYDOWN() check in addition to a WAIT(-1). I do this in my COLUMNS program so that the game detects both a single keypress as well as keys that are held down.

Edit:

Possible bugs?
1) Select an element, press ENTER. Then press HOME. Now, scroll the screen and press ENTER (don't choose a new element). --> nothing happens
2) Select an element, press ENTER. Then press HOME. Now, choose to menu option. Press OK when given the prompt and return to the table. Now press ENTER. --> nothing happens