01-03-2014, 10:31 PM (This post was last modified: 01-04-2014 04:55 AM by Han.)
Post: #1
 Han Senior Member Posts: 1,810 Joined: Dec 2013

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

Attached File(s)

Graph 3D | QPI | SolveSys
01-03-2014, 10:46 PM
Post: #2
 ArielPalazzesi Member Posts: 90 Joined: Dec 2013
01-04-2014, 04:45 AM
Post: #3
 Han Senior Member Posts: 1,810 Joined: Dec 2013
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.

Graph 3D | QPI | SolveSys
01-04-2014, 09:27 AM
Post: #4
 ArielPalazzesi Member Posts: 90 Joined: Dec 2013
"Indexed color 'mode? I did not know there was anything like this in HP Prime. Where I can learn more about that?
01-04-2014, 02:57 PM
Post: #5
 Mic Member Posts: 131 Joined: Dec 2013
Very good work Han.

01-04-2014, 03:55 PM
Post: #6
 Han Senior Member Posts: 1,810 Joined: Dec 2013
(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.

Graph 3D | QPI | SolveSys
01-04-2014, 07:51 PM
Post: #7
 ArielPalazzesi Member Posts: 90 Joined: Dec 2013
(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.

Post: #8
 The Shadow Member Posts: 220 Joined: Jan 2014
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.
01-08-2014, 05:07 AM (This post was last modified: 01-08-2014 05:13 AM by Han.)
Post: #9
 Han Senior Member Posts: 1,810 Joined: Dec 2013
(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;

Graph 3D | QPI | SolveSys
01-08-2014, 10:14 AM
Post: #10
 The Shadow Member Posts: 220 Joined: Jan 2014
(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.
01-08-2014, 06:20 PM (This post was last modified: 01-08-2014 06:21 PM by Han.)
Post: #11
 Han Senior Member Posts: 1,810 Joined: Dec 2013
(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.

Graph 3D | QPI | SolveSys
10-07-2016, 07:38 PM (This post was last modified: 10-18-2016 09:29 AM by junioratn.)
Post: #12
 junioratn Junior Member Posts: 1 Joined: Oct 2014
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.

Attached File(s)