[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] usage of wind_calc()

Hello,


 Yes, the toolbar matter is closed, if the appl_getinfo() implemented in
XaAES is OK for all :)


I think it's OK for all.

This is now in the gemlib documentation ;)



BTW, just two words about this. The idea is to allow an application to
change size & position of foreign window (window owned by another
application), right ? I see only two ways to do that :

1. by using AES messages : the application sends WM_MOVED (for example)
message to the other application, and the other application (which owned
the targetted window) changes the position/size of this window.


 This is the only method of modifying window position of windows owned
by other applications.
2. by using remote control mechanism, for example GEMSCRIPT commands : the 
application sends commands ("open file.txt", "move_window file.txt" for
example) to the other application, and the other application will execute 
the commands received.


 Much like the way AV_PROTOCOL works?
I don't know very well the whole AV_PROTOCOL but i'm pretty sure GEMSCRIPT is much more powerfull.
The message between application is not just a message number, it's a whole text string, with arguments. And the other application can answer with a string or a number or several arguments. 

I can give you an example to illustrate what we can do with GEMSCRIPT.

visit http://gemtidy.free.fr at the bottom.
GEMtidy can interact with EZ-edit, LUNA and JOE at the moment. The text editor propose an entry to the user to run gemtidy. In JOE it's in the list of modules of JOE, in EZ-edit it's an entry in the menubar, in LUNA it's a luna plugin. When the user clic on this entry, the editor starts GEMtidy (if not already started), and the editor send a command to gemtidy, for example the command "Verify file.htm", and then gemtidy verify the HTML file and reports errors in a window owned by GEMtidy (this window is customized depending on the caller -- see the icons in the snapshots). When the user clic on the GEMtidy window, for example over the text "line 5 col 12: syntax error", then GEMtidy sends a command to the text editor : "Open file.htm, top the window, and set the cursor at line 5 column 12". 

here is an example of what GEMSCRIPT allows.
There is a library (GSlib) for windom that allow the programmer to easily manage GEMSCRIPT protocol in its application. 


The 1st solution works for all applications (even to control windows of
old applications). It's the universal way, but the application has to know internal stuff of the foreign windows. For example, if you want to control the window of a text editor where the file "file.txt" is edited, then the 
application have to know the AES window handle of this foreign window,
which is not so evident.


 I dont see the problem here. What exactly is the hard part?


example :
an application (the project manager) commands to the text editor (qed) to edit file1.c (this can be done by using VA_START). 
Later the project manager commands to the text editor to edit file2.c.
Now the hard part : the project manager wants to TOP the qed window that contain file1.c... The solution is to send a WM_TOPPED message to qed... but what is the handle of the targetted window ? How the project manager can have this information ?
With GEMSCRIPT, we just have to send a command "put on top the file file1.c". 


BTW, with the WORK stuff in xaaes, this will no more work, because the
content of WM_MOVED messages depend on choices make by the application for 
this window.


 This is not true. The AES will make sure the application gets the
correct data.


oh! i see.
It seems that you are not aware that messages are very widely used. It's not only messages that AES build for an application. This may be message that an application sends to itself, or a message that an application sends to another application. 

It's really widely used.
An you cannot safely let the AES modify such message. If an application sends a message, IMO it's not acceptable that the AES modify the content of the message. The AES shall sends the message as this, with no modification ! 

BTW, i still don't see what all this is usefull for.
The last sentence is not just another sentence, IT'S THE MAJOR QUESTION that have to be answered before going too far. 


 There are certain data about windows that is accessible (read only) by
any application indipendant of window ownership. These include window
positions, state (ontop/untop/shaded/iconified, etc) and a few other
things. What is not possible is for foreign apps to modify any of these
things. So to do that, the relevant WM message is used.
Just curious : how can an application know what's the FULL area of a foreign window ? What's the magical AES call to do that ? mt_wind_get() with a copy of the aes_global[] array of the foreign application ? 


best regards,
Arnaud.