From: Mark M. <mie...@gm...> - 2012-01-09 21:07:02
|
On Mon, Jan 9, 2012 at 12:32 PM, Oliver Sims < oli...@si...> wrote: > ** > Two little things: > > (1) On my (slow) system, I had to insert a "call syssleep(1)" in the > program just after line 12: > dlgB~executeAsync("SHOWTOP") > call sysSleep(1) -- OS > dlgA~bIsNowAlive > > Without this, the program sometimes worked an sometimes didn't. The > "sometimes" pointed to a possible timing problem. > I found that when it didn't work, the client area of B was 0,0,0,0 - > suggesting that client area B was being set before dlgB was up and running. > The sysSleep fixed it. > > Yes, I put the example together in a hurry. The better way to fix it is this: Change the start up code to this: .application~setDefaults( , , .false) dlgA = .SimpleDialogA~new dlgB = .SimpleDialogB~new dlgA~dlgB = dlgB dlgB~dlgA = dlgA dlgA~popup("SHOWTOP", IDI_DLG_OOREXX) dlgB~execute("SHOWTOP") and move the self~dlgA~bIsNowAlive to the initDialog() method of .SimpleDialogB The reason being, dialog A wants the window handle of dialog B to get its client area. The window handle for a dialog is 0 until the underlying dialog is created. In the initDialog() method of dialog B, we now know for sure that the underlying dialog is created and its window handle is valid. So, this is the best place to signal dialog A that the window handle of dialog B is good. The method could maybe be better named 'dlgBHasHWND' or some other verb than 'isAlive'. > > > (2) I've added an Appendix 4 to the Guide. It's an aide memoire about > dialog creation which I did for myself, and thought it might be useful for > newbies to ooDialog. I'd be grateful for any comments you might have on it, > but it's not at all urgent. > > > I glanced at the XML when you made the commit. The idea of adding it is great, I've had people tell me that, that type of thing would be helpful. Since it was XML, I didn't read it to closely for content. > > Atb, > Oliver > > > ------------------------------ > *From:* Mark Miesfeld [mailto:mie...@gm...] > *Sent:* 07 January 2012 19:47 > *To:* Oliver Sims > > *Subject:* Re: [Oorexx-users] ooDialog - Drag/Drop > > Hi Oliver, > > Attached is a working drag and drop between 2 programs. It is rough, I > did it it in hurry. But it shows the technique works. > > I'll try to take a look at your code, but maybe a working example will be > just as much help. > > Note this message sent to you personally, not the list because the list > does not accept attachements. > > --- > Mark Miesfeld > > On Sat, Jan 7, 2012 at 11:28 AM, Oliver Sims < > oli...@si...> wrote: > >> ** >> Sorry, I just didn't mention it - I did get messages sent to A. >> (I also got move messages sent to B *after* the drop). >> >> Also, I did capture the mouse in A, but not in B. >> >> In case it helps, I'll send you the test harness I'm using. There may >> well be gotchas in my code!! >> >> Thx, >> >> Oliver >> >> >> ------------------------------ >> *From:* Mark Miesfeld [mailto:mie...@gm...] >> *Sent:* 07 January 2012 18:22 >> *To:* Open Object Rexx Users >> *Subject:* Re: [Oorexx-users] ooDialog - Drag/Drop >> >> On Sat, Jan 7, 2012 at 9:52 AM, Oliver Sims < >> oli...@si...> wrote: >> >>> ** >>> This is a question on drag/drop. >>> >>> I have two dialogs A and B running in the same process (i.e. both >>> started by a single script). >>> Both dialogs are "mouse-enabled" (that is, both connect to mouse events, >>> and A also sets the mouse cursor on Button1Down). >>> >>> So, I pick up on A and drag the cursor over B. >>> When dragging over B, I get no messages sent to either A or B. >>> >> >> This doesn't sound right to me. If you captured the mouse in A when you >> did the 'pick up' all mouse messages should be sent to A, until you release >> the mouse. On the face of it, I don't think you captured the mouse. If >> you did, then I guess I'll need to play with this a bit to see what is >> happening. >> >> >> >> >> >>> So I cannot set the cursor appropriately. >>> When I drop on B, I get a MouseMove event sent to B. >>> >>> However, when the cursor is over B, I want to change it to an >>> "OkayToDrop" cursor. But with no messages sent to either A or B, I conclude >>> that I cannot set the cursor to OK on the basis of a message being receive >>> by B. >>> >>> >> >> The conclusion is wrong, you can set the cursor. You should be getting >> messages sent to A, I think, as explained above. >> >> >> >> >>> >>> My question: Is this the only way to determine when the mouse is over >>> the target? That is (ref the A and B example above) have the A determine, >>> on a MouseMove message sent to it, whether the cursor is over B or not? >>> >>> >> >> The answer to the question is: Yes, this would be the only *reliable* >> way. But, you *have* to capture the mouse. >> >> Think about a scenario using your first approach. We have A and B >> dialogs again >> >> mouse moves over A, detect button down, detect mouse leaves A and detect >> button still down; >> detect mouse enters B and detect button still down, detect button goes >> up, do drop >> >> This would work, provided the user does not drag the mouse over a >> drag-enabled window between leaving your A and entering your B, because the >> drag enabled window will take control of the mouse. >> >> But, of course you can not count on the user doing that, so your first >> approach while reasonable, is not reliable. >> >> I'll try to a look at the 2 dialog scenario. I still believe it is >> doable. >> >> -- >> Mark Miesfeld >> >> >> >> ------------------------------------------------------------------------------ >> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >> infrastructure or vast IT resources to deliver seamless, secure access to >> virtual desktops. With this all-in-one solution, easily deploy virtual >> desktops for less than the cost of PCs and save 60% on VDI infrastructure >> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >> _______________________________________________ >> Oorexx-users mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-users >> >> > |