Example: creating icon menus

[Han]

Link to DIMGROBHELPER: DIMGROBHELPER

Code:


export iconmenu()
begin   local i,key,getmouse=1;
  local cmode,tmode,showbox;
  dimgrob_p(G4,320,70);
  dimgrob_p(G5,320,70);
  blit_p(G4,G0,0,120-35,320,120+35);
  dimgrob_p(G3,320,70,0);
  blit_p(G3,13,3,"xyicon");
  blit_p(G3,90,3,"zicon");
  blit_p(G3,167,3,"boxicon");
  blit_p(G3,244,3,"traceicon");
  for i from 1 to 35 do
    blit_p(G0,0,120-i,320,120+i,G3); 
    wait(.01);
  end;

  while getmouse do
    key:=WAIT(-1);
    if TYPE(key)==6 then
      if key(1)==3 then
        if 90<key(3) AND key(3)<150 then
          case
            if 15<key(2) AND key(2)<75 then cmode:=0; getmouse:=0; end;
            if 92<key(2) AND key(2)<152 then cmode:=1; getmouse:=0; end;
            if 169<key(2) AND key(2)<229 then showbox:=NOT showbox; getmouse:=0; end;
            if 246<key(2) AND key(2)<306 then tmode:=NOT tmode; getmouse:=0; end; 
          end;
        end;
      end;
    end;
  end;

  for i from 35 downto 1 do
    blit_p(G5,G4);
    blit_p(G5,0,35-i,320,35+i,G3);
    blit_p(G0,0,120-35,320,120+35,G5);
    wait(.01);
  end;

  blit_p(G0,0,120-35,320,120+35,G4);
  return(tmode);
end;

// icon data removed; see attached zip file below

[ArielPalazzesi]

[Han]

LOL! I suppose now would be a bad time to confess that I forgot to reduce the colors of the icons, which could have saved an additional 20KB or so. Anyway, if limiting the palette does not affect (too much) the quality of the images being used, then a lot of memory can be saved by switching over to "indexed color" mode.

[ArielPalazzesi]

"Indexed color 'mode? I did not know there was anything like this in HP Prime. Where I can learn more about that?

[Mic]

Very good work Han.

[Han]

(01-04-2014 09:27 AM)ArielPalazzesi Wrote:  "Indexed color 'mode? I did not know there was anything like this in HP Prime. Where I can learn more about that?

I meant to write that the colors in the graphic object should be indexed (for example, in Photoshop) before importing to the calculator to save space.

[ArielPalazzesi]

(01-04-2014 03:55 PM)Han Wrote:  I meant to write that the colors in the graphic object should be indexed (for example, in Photoshop) before importing to the calculator to save space.

Thanks. Reading about this....

[The Shadow]

Hi, new to the forums here.

This program is really awesome - it's much easier to do than I was expecting!

Question: Is it possible to differentiate between regular and long clicks? I ask because from messing around with it, it seems that every long click first reports as a regular click.

To be clear, I'd like to have a menu in which a regular click on an item does one thing, and a long click on it does another.

[Han]

(01-08-2014 03:58 AM)The Shadow Wrote:  Hi, new to the forums here.

This program is really awesome - it's much easier to do than I was expecting!

Question: Is it possible to differentiate between regular and long clicks? I ask because from messing around with it, it seems that every long click first reports as a regular click.

To be clear, I'd like to have a menu in which a regular click on an item does one thing, and a long click on it does another.

If using WAIT(-1) to detect the mouse, then it is possible to detect the mouse clicks (long vs short). When a mouse event occurs, the WAIT(-1) command returns a list whose first entry determines the mouse event type. A 3 means a click occurred and a 7 means a long-click occurred. Please note, however, that clicks cause several events. A single click will actually trigger three events: mouse down, mouse up, followed by the actual "click". A long click triggers: mouse down, mouse up, long click, and finally regular click. Thus, your mouse event handler code MUST handle the long click FIRST, and enable some sort of local flag so that it does not also trigger the extraneous click event. Below is the code to test click events and what the WAIT(-1) returns.

For some strange reason (likely a bug), a long click is never generated if your first mouse event is in fact a long click!

Code:


EXPORT TEST()
BEGIN
  local getmouse=1, key;

  while getmouse do
    key:=WAIT(-1);
    if TYPE(key)==6 then
      if key(1)==3 then
        rect(); textout_p(key,0,120); wait(.5);
      else
        rect(); textout_p(key,0,0); wait(.5);
      end;
    end; 
  end;
END;

Here's how I would create the mouse handler:

Code:


local lclick=0, getmouse=1, key;

while getmouse do
  key:=WAIT(-1);

  // YOU MUST HANDLE MOUSE CLICKS BEFORE KEY PRESSES
  if TYPE(key)==6 then

    case
      if key(1)==7 then
        lclick:=1; // tell future events we just had long click
        // insert long click code here
      end;

      if key(1)==3 then
        if lclick then
          lclick:=0;
          // fake mouse click; add code here if you still want to handle it
        else
          // insert code here for true single-clicks
        end;
      end;

      // any other mouse events handled here must also set lclick to 0

    end;

  else

  // here is where you place the key-press handlers

  end;

end;

[The Shadow]

(01-08-2014 05:07 AM)Han Wrote:  For some strange reason (likely a bug), a long click is never generated if your first mouse event is in fact a long click!

Many thanks for the detailed response! It's this bug that was tripping me up - I was never seeing the 7 show up.

Just to make sure, this bug means that in order for the long-click code to work, you first need to touch the screen somewhere besides the 'active' area, right? Otherwise the bug will ensure that a long-click is never caught.

[Han]

(01-08-2014 10:14 AM)The Shadow Wrote:  

(01-08-2014 05:07 AM)Han Wrote:  For some strange reason (likely a bug), a long click is never generated if your first mouse event is in fact a long click!

Many thanks for the detailed response! It's this bug that was tripping me up - I was never seeing the 7 show up.

Just to make sure, this bug means that in order for the long-click code to work, you first need to touch the screen somewhere besides the 'active' area, right? Otherwise the bug will ensure that a long-click is never caught.

In general, you just need to have touched the screen anywhere, really. If you are referring specifically to the example in the original post, then yes -- avoid the 'active' area. Only after some other touchscreen event has occurred will WAIT(-1) properly detect the long click.

[junioratn]

Hello

very good code congratulations

as it does to link with a program?
for example when you click on one of the images from your code it execulta another program.
I would like to put this code attached for me to see how it looks.