[Solved] Application library event handling

The documentation is a bit thin on how to handle events for an appwindow.

I want to identify iconify/deiconify events within the appwindow event loop:



Anyoen know how to get the iconification stuff into my event loop?

@orgin

You need to Wait() on the application.library signal and then handle the events as you would for any other messages.

struct MsgPort *applport;
GetApplicationAttrs(appID, APPATTR_Port,(ULONG)&applport, TAG_DONE);
applsig = (1L << applport->mp_SigBit);

wait = Wait(applsig);

if (wait & applsig)
{
// application.library signal

while ( (applmsg=(struct ApplicationMsg *) GetMsg(applport)) )
{
switch (applmsg->type)
{
case APPLIBMT_Hide:




etc

@Chris

I'm already allocating message port and doing the wait stuff in an outer loop. So I already have that bit covered.

Anyway, "HIDE" is application.library acronym for iconify?

If not then I hope you'll eventually realize what I was asking for, that is: how to combine reading both WMHI_* messages and the application.library messages in the same event loop. (GetMsg() + RA_HandleInput() on the same message port)

@orgin

No, HIDE is the event I had at the start of the code I copied and pasted.

All you need to do is put the HandleInput in a if(wait & winsig) section, rather then immediately after Wait()



wait = Wait(winsig | applsig)

if(wait & applsig)
{
// GetMsg() for application.library
}
else if(wait & winsig)
{
// RA_HandleInput() for Reaction
}

@orgin

If you make your Reaction window an appwindow, why don't you use the AppMsgHook feature ? The hook will be called automatically by RA_HandleInput() when an AppMsg is received, so you can use the loop code provided by Chris ?

@centaurz

Probably because I have no idea what you just said nor how to incorporate it into my app.

I have two message ports. One for the appwindow stuff (WINDOW_AppPort+WINDOW_AppWindow=TRUE) and one for the GUI (WINDOW_SharedPort).



@anyone

Btw, I noticed that I get an ApplicationMsg when I drag&drop something on my appwindow, but there's no mention of how to retrieve information (multiple file for example) from the message in the autodoc. There's the appwindow method OpenDoc but that only takes a single file path.

@Chris

Doesn't two different sigbits need two different msgports? (There's no way to specify two different ports for this)

@orgin

Um, maybe, the application.library msgport will be different anyway.

I also think you're confusing AppWindows with application.library. AppWindows are handled by workbench.library with AddAppWindow() and the usual GetMsg(), and are only for dragging icons into windows (but share an interface with AppIcons and AppMenus).

application.library is more like commodities.library, and allows you to control an application from elsewhere (usually AmiDock)

Don't mix the two up or you won't get anywhere.

Chris

@orgin

Are you sure you're not mixing application.library and workbench.library?

An AppWindow has nothing to do with the application.library. It's from workbench, see AutoDoc for workbench.library/AddAppWindowA

The AppMessage is defined in workbench/workbench.h

If you have two ports, each port will have it's own signal. You get the mask for every port and than wait for the signals.

@Gazelle

Quote:

Ahh, seems that's what I'm doing, thanks. Finally the message makes sence. If I deiconify the window I get am_Type 8 (AMTYPE_APPICON). And the same if I drag&drop some icons on it. What information in the message tells me what the user is trying to do?


(The rest of you message is not relevant to what I'm doing)

Solved it :) The code ended up like this:



Next up is trying to figure out how to drag _from_ my application.

@orgin

Quote:

I don't think there's an easy way of doing that unfortunately. I could find a use for this though.

@Chris

Hmm okey, would be nice to be able to create a dragcontext when detecting a drag event in your window. And then intuition/workbench takes over. Once dropped intuition/workbench sends a struct *DropMessage to the receiving window.

struct DropMessage could contain:

@orgin

You should also handle AMTYPE_APPWINDOW type Messages. Don't know why you only get AMTYPE_APPICON but as I understand the autodoc you should receive one type for your AppIcon and the other for your AppWindow.

@Gazelle

Yes I'm receiving both. That code has been updated a bit since I pasted it here.

@Chris

what would you think of this?:

@orgin

You need a tag to specify the image that is being dragged too. Probably a struct Icon * will be best for Workbench.

I'm not sure DropMessage is needed - anything you will be dragging to would have already registered as an AppWindow or AppIcon, or be Workbench.

The data could be passed in a tag, perhaps WB could store it in a temporary file and then pass the filename. Needs some sort of notification to delete the temp file once it has been finished with (incidentally this is how RISC OS manages dragging directly from one app to another, not sure if the app or the OS writes the temp file though)

Other than that, looks good. Where did I put Workbench's source code?

@Chris

"Where did I put Workbench's source code?"

Well I'm sure that if a proposal was written I could find the right people to send it to for consideration.

@orgin

I see why you had DropMessage now - for dragging bettween windows belonging to the same application. I think an extended AppMessage structure would be better.

AddAppWindow() and AddAppIcon() could have a new tag:
WBAPPICONA_AllowData
WBAPPWINA_AllowData

This would tell WB that the application is happy to receive data passed in memory as well as filenames.

CreateDragContextAttrs() would then need the following tags:
DC_Data (APTR) pointer to memory area holding some data
DC_DataSize (uint32) size of DC_Data

Also useful might be
DC_UserData (APTR) for other information to pass through AppMessages
and the aforementioned DC_Image (struct DiskObject *)

Only one of DC_Data or DC_ArgList must be supplied.

struct AppMessage would then need the following additions:
am_Data
am_DataSize
am_DCUserData

If the calling application uses DC_Data and the user drags onto an application which does not have WBAPP_AllowData tag set, Workbench would transparently write the data into a temporary file in T: and pass the filename instead.

I haven't figured out yet how WB will know that the temporary file has been finished with (or, indeed, how the calling app will know that the in-memory data can be freed - maybe the receiving app/WB should take care of that?)

@Chris

Quote:

Where do you have this ? I don't have that in the current SDK.