[Solved] Application library event handling

@TSK

I don't - it's a proposal. Read from about post 13 onwards...

@Chris

Quote:
?h, oh, just realized. It's a very good proposal ! I second that idea !

@Chris

Perhaps workbench can delete the file in ram: when you IDOS->Reply() the message?

Which means that you must retrieve and copy the data before calling Reply().

@orgin

I think that would work - some testing would be needed to see how many apps do this. I guess for any apps that don't do it, it's no biggie if it doesn't work, and they can be fixed up if they are still being maintained.

@All

Could someone post the struct AppMessage definition here? I don't have the autodocs at hand right now.

@Chris

Wrote a proposal in autodoc format:

@orgin

>?DC_Icon?(struct?Icon?*)
That should be struct DiskObject * I think. That was my mistake earlier.

> ?DC_Data?(struct?IFFHandle?*)
I don't think we should be limiting ourselves to IFF data. If I drag something out of my app into a Workbench window, I'll want it to stay in whatever format it is now. If I drag some text into Notepad, it won't like it if it is IFF FTXT. I think forcing IFF here will cause more problems than it solves.

Using IFF would be useful if it was on the clipboard, and the drag event told the receiving application to do a paste. That is more complicated and not as backwards-compatible although it could be useful in some circumstances.

A tag is also needed for "default filename" or somesuch, so Workbench knows what to call the file if something is dragged into a Workbench drawer window.

am_data isn't necessary - the filename should be passed in the ArgList like any normal file. It could be used for a pointer to the data though.
am_posx and am_posy are already available in the AppMessage structure.




#define AM_VERSION 1

struct AppMessage
{
struct Message am_Message; /* standard message structure */
UWORD am_Type; /* message type */
ULONG am_UserData; /* application specific */
ULONG am_ID; /* application definable ID */
LONG am_NumArgs; /* # of elements in arglist */
struct WBArg * am_ArgList; /* the arguments themselves */
UWORD am_Version; /* will be >= AM_VERSION */
UWORD am_Class; /* message class */
WORD am_MouseX; /* mouse x position of event */
WORD am_MouseY; /* mouse y position of event */
ULONG am_Seconds; /* current system clock time */
ULONG am_Micros; /* current system clock time */
ULONG am_Reserved[8]; /* avoid recompilation */
};

/* types of app messages */
#define AMTYPE_APPWINDOW 7 /* app window message */
#define AMTYPE_APPICON 8 /* app icon message */
#define AMTYPE_APPMENUITEM 9 /* app menu item message */
#define AMTYPE_APPWINDOWZONE 10 /* app window drop zone message */

@Chris

> That should be struct DiskObject * I think. That was my mistake earlier.

Ok changed.

> I don't think we should be limiting ourselves to IFF data.

The reason for IFF data is because you can type set the data in a generic way. The receiving application can check the types and extract the information it can read and discard the rest. It might a bit inconvenient but sometimes it's good to enforce rules.

Sending arbitrary random data will be a bit messy, since other applications would have no way of knowing if it's data they can handle or not. IFF is a tried concept and that's why I selected it. Plus it's already used for the clipboard so it's not something new people would have to learn. For example, any app that can receive a dropped image will be able to do so regardless of who created it.

But if you start allowing random data then two apps dealing with their own internal data structures they won't be able to discern if they can deal with data from each other. (they will probably crash and burn after typecasting the data or do something else they shouldn't.)

Plus you can always insert random application specific data in an iff structure and only deal with it if it's from a known source (am_win), other apps simply won't deal with it.

> A tag is also needed for "default filename" or somesuch, so Workbench knows what to call the file if something is dragged into a Workbench drawer window.

Should probably be able to handle the situation of the file already exists and add a sequence number. Ie:

dropclip
dropclip1
dropclip2
etc

#define DC_BASENAME "dropclip" // When dropping am_Data onto the wb
#define DC_DROPCLIP "ram:t/dropclip" // For temp storage in ram

> am_data isn't necessary - the filename should be passed in the ArgList like any normal file.

Using separate field for it allows the receiving application to know what the sending application intended to do and there won't be any confusion between new and old applications (and new/old workbench). Should the file be copied/moved/opened or should I use it as a drag data (insert text in a text field or other application specific handling). Giving your app the option to react differently depending on if you drag a file from a lister into your app or dragging some other application specific data. Old apps and workbench will simply not deal with the new data until they are updated to handle it, they will just see it as a attempt to deiconify a appicon.

(I wonder if the workbench sends IDOS->Reply() before moving/copying any files. It probably does. Which means that the dropclip file would be removed before it can deal with it. Hmm... I wouldn't be surprised if most apps replies as fast as possible which would mean that using am_data is the better way, ie. the apps and wb would have to be updated if they want to able to deal with the dropclip file)

> It could be used for a pointer to the data though.

Ouch, I think that would open up a can of worms that shouldn't be opened. Random apps scanning into your data without knowing what it is. And if you decide that it should always be a certain format you still have to decide who should deallocate it (the wb probably being the best idea.)

> am_posx and am_posy are already available in the AppMessage structure.

Okey removed

The struct you posted, it it the actual current appmessage? I didn't get to check that in the sdk last night



Anyway, I don't think we should try to find the absolute 'optimal way' of doing this and then present it as such. We probably won't be able to agree on all points and then just get upset with each other (like Amiga folks usually do in that 'it's my way or the highway mentality' ;) or simply never get it done. It's better to just present an idea and then let Hyperion either discard it as a whole or change it into whatever they think is best.

@orgin

Quote:

I get your point, but any app or Workbench that I am dragging my data onto will be handling it just like any other file (hence why it should go into a temp file and be passed using the usual am_ArgList). There is no more danger from doing this than dragging the same file saved on disk into an AppWindow.

I've just added drag-saving into NetSurf (which is why I was interested in this topic), and if I'm dragging a JPEG on to Workbench I want WB to save a JPEG on disk, not an IFF (there is a key combo - not yet implemented - for that though)

Quote:

That rather limits the usefullness.

Quote:

WB is only saving the file to where you drag it, it needs to be updated anyway to add this new function, I don't see a problem there.

Any apps that reply too quickly will just not be open a file. No big problem there.


Quote:

Yes, it is.

YAM is a good example. If somebody sends me a PDF, (a) there isn't an IFF equivalent anyway and (b) I'd want it to save as a PDF, or open if I dragged it over AmiPDF.

Same with archives (.lha etc)

@Chris

Check new proposal.

@orgin

Happy with that

Couple of minor points though:

1, Is a window pointer enough for internal drags? This would require the application to check the window pointer against all windows, and probably look at WINDOW_UserData (although I'm not sure if you can use that with non-window.class windows - actually I've just noticed DragType so this might not be an issue anyway). It might be advisable to have a little more security for drags that are intended to be internal only - eg. new datatype DC_DATATYPE_PRIVATE, and a caveat that the application must check that DragType and the window pointer are valid for the app.

2. Filename for DC_Data drags to Workbench. I've been thinking about this, and it's probably best if WB prompts for a filename before writing the file, rather than having an iffy one hard-coded by the application/workbench.

This is an interesting proposal. I'd be very interested in seeing some final documentation on this, and see just how viable this would be.

Simon

@orgin

Extension:
DC_Data NULL, DC_NumArgs 0, am_win NULL should be valid.
In this case only Workbench drawers are valid target for drags (no AppMessages). No file will be created - this will be left to the calling application to write it after the function returns.

New tag DC_Destination (STRPTR) if passed a pointer to a string, will populate this string with the path where the icon was dragged, or a NULL string (if dropped onto an AppWindow, WB backdrop etc).

This tag would probably only be of use for drags to Workbench. With DC_Data and DC_NumArgs NULL/unspecified we have a simple equivalent of what can be done with WhichWorkbenchObject(), although with proper icon dragging imagery and support for drags across screens.

Intended for situations where more than one file needs to be written to the destination. Application checks the result of DC_Destination and writes the additional/all the files.

@Chris

I dislike the idea of the workbench windows being treated like a special case. A third party application (like this one) should be able to act just as if its windows were workbench drawer windows.

If this is an 'absolute must have' functionality then I'd prefer if one could send an AppMessage that just queries the receiving window for a path. However all of this would require that the workbench library function is blocking the sender until the receiving application sends reply. And if it doesn't then your app is toast, frozen up, ie dragging into a killed app will also kill your app, if the receiving app has opened a requester and isn't listening for AppMessages at the moment you app will also be waiting until the requester is closed.

I think it's better if the workbench function just blocks until the mouse button is released so that there is no connection between the state of the receiving app and the sender. Once the message is dispatched its no longer the sending apps business what the receiver does or doesn't do with it. That is, in this case your function can't be implemented without some safeguards for knowing when you have received the data, either by checking the STRPTR periodically or adding a callback message using message ports or somesuch.

Anyway, this particular functionality can be implemented using am_ArgList anyway, with the inconvenience that the sender would have to create the files first. So I don't know, It doesn't seem to me as if that inconvenience merits adding special cases into workbench blocking 3rd party apps from acting the same nor the extra complexity it adds.

@orgin

That's why I said a tag - WB knows the path as soon as you let go of the mouse button.

It's not absolutely essential, it just reduces complexity for apps that need to write a lot of data, or a whole drawer of data. It's better not to put masses into a temp file, plus you have to delete it manually and the calling app won't know when the receiver has finished with it.

I just don't think it's practical to write a whole drawer of stuff without this.

btw, I agree that blocking the caller until a ReplyMsg() comes is a very, very bad idea. For one it'll cause a deadlock if the user drags something from an application back into the same window or another window belonging to that app.

Chris

@Chris

"That's why I said a tag - WB knows the path as soon as you let go of the mouse button."

Which makes wb behave in a special way that other apps cannot imitate.


What about making it this way instead then (which mirrors the <=4.1 behaviour in a better way):

DC_DataNumArgs (LONG)
Number of DropBlocks in DC_DataArgList. Default 0.
DC_DataArgList (struct DropClip **)
Array of Drop Clips. Default NULL.

struct DropClip
{
APTR DC_Data; // Pointer to arbitrary data or struct IFFHandle
WORD DC_DataType; // DC_DATATYPE_DROPCLIP/DC_DATATYPE_BINARY
ULONG DC_DataSize; // Size of DC_Data
};

With am_NumArgs/am_ArgList mirroring it in the resulting AppMessage. With each entry being called "dropclip.0", "dropclip.1" .. etc.

@orgin

I haven't read the whole thread but if the idea was to make drag&drop from a 3rd party software to WB. If it was possible to get a list of app windows from WB then create an AppMessage and send it to a port of that window (where you're dropping the file). You can find a WB drawer with WhichWorkbenchObject(). Btw. Why do think type of a file matters anything ?

@TSK

You probably need to read the whole thread to understand this.

@orgin

Oh, yes. I like that.

Need to create a dir in the destination location as well though

Hmm... maybe creating it temp in RAM: and then passing the dir name is the answer.

...but then there's no way of knowing when it is safe to delete.