Making a commodity - some questions

[peceha]

Hi
for last few days I've been writing small program - just another screen manager , but I think a little bit more fancier than common AltTab programs. You can download it here if you want (for classic amiga):
http://s000.tinyupload.com/?file_id=...83443167395907

this is how it looks like so far:
[ Show youtube player ]

just make sure that you have some screens open and press [RALT] [ARROW DOWN] to display the window.
Use [UP],[DOWN] arrows to move through the list and accept your choice with [ARROW RIGHT] or dismiss the window with any other key or mouse move.



now Questions:
1. Is there a way to get a notification when a key was released? - Blitz commodity library lets me assign a shortcut but it fires up when the key is pressed.
2. Is there a way to get a notification from the system when the screen was closed? - I need it to make it more safe when dealing with customs screens.

Thanks


I forgot
3. How to pass information from toolTypes into my Blitz program? I already know Par$ and NumPars but that's for CLI.

[Daedalus]

1. Hmmm... That's not just Blitz - Commodities respond on the keydown event since the input.device processes the "cooked" input data, i.e. translated for different keyboards, and not the raw data from the keyboard. It's not ideal, but you could probably respond to the event by waiting until the key is released by checking the raw keycodes. Pretty messy I would suspect however.

2. Not that I know of. The list of screens is quite quick to traverse however, so maybe you can rebuild the list whenever you need it - when the keypress is triggered for example.

3. Are you using AmiBlitz3? The dos.include file has a number of functions that use the OS to read and write tooltypes, such as dos_GetToolString{}, and it works very well. If not, there are some commands in the extra user libs that should do the job as well. Check out AaronsIconLib for example, with commands like GetIconInfo(), IconTool$() etc. NToolTypes is another library with similar commands that should work too. I haven't tried either, but read the documentation on them and try them out.

[peceha]

Thanks for the answers.
1.In that case it's better if I just drop the idea with "key up" event
2.Ok, my list will get an update just after key was pressed.
3.Nope, just Blitz2 but now I know what to read.

Thanks again.

[peceha]

Back to my exercises

As my project is still evaluating I was wondering how to handle key presses.

To call the program's window the following keys combination must be pressed: [RALT] [ARROW DOWN]
That combination is assigned via SetHotkey command from RICommoditiesLib.

At the moment, all other keys (scrolling the list, choosing the screen...) are handled the same way (via SetHotkey). Is this a correct way (all shortcuts are like a global now)?

Maybe I should only set [RALT] [ARROW DOWN] via SetHotKey and all the rest should be handled by window's IDCMP_RAWKEY (once the window is shown)?

That idea just came to my mind and I don't want to rewrite a lot of code just for nothing so I'm asking - is it worth it?

Thanks

[Daedalus]

It seems you're talking about two different things here. A commodity typically only has one hotkey, which is used for calling up the program. This is what SetHotKey sets, and is the mechanism used for Exchange (Ctrl+Alt+Help), Blanker (Ctrl+Alt+B), and so on. If you're trying to capture multiple key combinations and act differently on them, you can do as you were thinking - open a window on the main hotkey and interpret the rest of the keys as key events. An alternative is to install a Commodity input handler, which hooks into input.device to capture global keys. This is what FKey does for example. This is a more advanced feature of commodities, and isn't supported by the RICommodities library. Instead, you should use the NCommodities library and set up Commodity Objects for each key you wish to capture.

I suspect mixing the two libraries won't work well, so you should use NCommodities library for setting up your commodity as well. It's more complicated to use this library, but in return it's more powerful...

[peceha]

Thanks,
I had a feeling I was doing something wrong...

[peceha]

I have not replaced the libraries yet (RICommoditiesLib with NCommodities) because I just stumbled upon one problem:

I need to listen to events from 2 sources so at the beginning of the program I have this line

AddWaitEvent PortSigBit(CommodityMsgPort),$800000

to catch the commodity stuff

and later, when my window is successfully open I have following line

AddWaitEvent PortSigBit(*win\UserPort),$900000

to be informed that some intuition event happened.

and the main loop looks like this:

Repeat
  Select WaitEvent
    Case $800000
      Gosub commPart:
    Case $900000
      Gosub IntuitionPart:
  End Select
Until quitFlag

The question is:
how can I get triggered IDCMP events in "IntuitionPart"?
When I try "Event" or "RawKey" I get 0.
Of course I do assign IDCMP Flags to #WA_IDCMP tag before the window shows up (INACTIVEWINDOW|MOUSEMOVE|RAWKEY).

I think I'm lost

[Daedalus]

The problem is that the value returned by WaitEvent is transient - once you get the value, it is gone. So you can only read it once. Try this instead:

ev.l = WaitEvent
Select ev

Now when you go to the IntuitionPart, just check the variable ev instead of Event.

[peceha]

I just did like you suggested ("ev" variable) and when I go into "intuitionPart" then:

NPrint ev

gives me 9437184 (which is $900000) no matter what I do (move the mouse, press a key or deactivate the window).

I think because of

AddWaitEvent PortSigBit(*win\UserPort),$900000

all my intuition events values are replaced with $900000 and I cannot find out what actually triggered an event.

Thanks.

[Daedalus]

Ah, sorry, I see what you're doing now. Well, assigning to the ev variable is the correct thing to do anyway, but I think you're flooding the system with more events than you can react to - all the events are queued up, and moving the mouse generates events faster than you can read them if your code is in any way slow (and NPrint is slow). What standard IDCMP flags do you have for the window?

[peceha]

Only 3:
#IDCMP_INACTIVEWINDOW
#IDCMP_MOUSEMOVE
#IDCMP_RAWKEY

First 2 are supposed to close the window if mouse was moved or window got deactivated.
Last one is for navigation within the window and should recognize: UP, DOWN, LEFT, RIGHT keys.

Earlier version (all shortcuts assigned with SetHotKey) was working correctly (although, now I know it was "badly designed").
I didn't have to care what event was coming from intuition - all of them just had to close the window so it was enough to response to $900000 in main loop.
If event came from commodity ($800000) then I used "CommodityEvent" together with "HotKeyHit" to find out what key was pressed and acted accordingly.

I used "NPrint" only to find out what was in the "ev" variable (it won't be there in final code)

[Daedalus]

Hmmm, when I'm next at my Amiga I'll have a look at exactly how it runs, but the mousemove event is triggered every frame, so you will get hundreds of them every time you move the mouse, and the extra one you've added I think isn't necessary. It might have worked accidentally before, since every second event code was swallowed by your code.

[peceha]

Thanks for your help - I think I wouldn't do any progress without it!

Back to the topic.
I know what I did wrong.. well, for me it didn't look so important but it turned out it was crucial
I forgot to mention that I used "OpenWindowTagList_()" to open the window and... in that case "WaitEvent/Event" doesn't return anything!! (my program is going to be very OS friendly )
I just added:

DEFTYPE.IntuiMessage  *msg
...
*msg=GetMsg_(*win\UserPort)
ReplyMsg_(*msg)
Select *msg\Class
  Case #IDCMP_RAWKEY
  ...
End Select

and ... there is again the light at the end of the tunnel

Thanks Daedalus for your time!

[Daedalus]

Excellent! Yep, doing it the proper OS way is nice, and one of the things I really like about Blitz is its ability to access the OS like that.

[peceha]

If someone would like to test the program the link in first post is now updated with today's version.
Also the video in first post shows today's version of the program in action.



Summary:
* uses toolTypes (mode,spacing,speed,ccolor)

* same arguments can be used from CLI
- mode: (default 0 - with "preview"), another possibilities are numbers from 1 to 9 (no screen preview - only window on front most screen)
- spacing: (default 2) how many pixels are added to font height to make a line height
- speed: (default 10) that is the speed of sliding down the screen
- ccolor: (default 3) pen number used for custom screens

* if a custom screen gets closed while the NotAnAltTab window is open then its entry will be crossed out from the list and it won't be possible to select it anymore

* mouse move, mouse buttons or keyboard keys other then arrows will dismiss the window right away (for safety purpouses)

* public screens always are first on the list then custom screens are displayed

* custom screens are displayed in different color on the list (ccolor)

* MultiView's screens are shown as "MV: and the window title"

* Unknown screens are shown as "?: and the screen number"



Bad things:
* if there are screens with different resolution and MODE=0 and navigating the list with ARROW UP then the ugly blink shows up - it is not happening when navigating with ARROW DOWN (the reason for this is that I have to set the preview screen second from top and to do this it must be front most for a fraction of a second - then the blink comes in)

* that program ignores (at the moment) overscanned screens - it means the window may show up out of the view (but I will fix it soon)

* some scrreen are no good to display the window (eg. AGMS Video) - in the future I will add a list containing screens to be ignored




And the more important:
thanks again Daedalus for your help!