Mark, the last time I wrote a dialog app it was in OS/2, so what I haven't forgotten is not applicable. I'm enjoying following your discussion here, regardless.
One of my pet peeves as a user, however, are non-resizable windows that are ignorant of the current font size. Sometimes I use my laptop to drive a digital projector and need to use a much larger font than normal. Is there any valid reason for creating a non-resizable window? A second peeve is the resizable window that refuses to remember the size I had to drag it to the last time. Disk Defragmenter comes immediately to mind. Is it that hard to make a dialog window smarter than a bag of rocks? -Chip- On 1/5/12 00:49 Mark Miesfeld said: > On Wed, Jan 4, 2012 at 2:50 PM, Oliver Sims > <oliver.s...@simsassociates.co.uk > <mailto:oliver.s...@simsassociates.co.uk>> wrote: > > __ > > Another question if I may: in mouseTrack.rex, the dialog size > (cx,cy) is 257, 123. But when checking if the mouse is outside the > dialog in the onMouseMove method, you check for the mouse position > being > 385,200: > > > > This is an area where the original ooDialog implementers made a huge > mistake, so I'm glad to discuss this. > > First off, dialog units are only intended as a way to produce a > dialog template that will work on any one's monitor. Once the dialog > appears on the screen, everything is in pixels. > > Second off, how dialog units map to pixels is 100% dependent on the font > of the dialog. > > The original developers made these big mistakes. > > 1.) They either did not know, or choose to ignore, the fact that a > dialog unit is dependent on the font of the dialog. So they had the > factoryX and factorY attributes, which they then promoted as being > capable of converting back and forth between dialog units and pixels. > But, the factor is completely wrong for any dialog that is not using the > archaic Windows 3.1 system font. Which is 99.9% of dialogs today. > > 2.) In the ooDialog implementation, they took values given to them by > the OS in pixels and convert them to dialog units. They ask for > arguments that should be in pixels, in dialog units and then convert > those dialog units to pixels. But, in both cases they use a conversion > factor that is incorrect. > > Once the dialog is on the screen, you should never use dialog units, you > should use pixels. The OS gives you values in pixels, the OS expects > you to return values in pixels. > > So that's my rant. <grin> Below are some practical answers. > > > > > ::method onMouseMove unguarded > expose ... dragging ... > use arg keyState, p, mouse > ... > if dragging then do > if p~x < 0 | p~y < 0 | p~x > 385 | p~y > 200 then do > ... > > How do I map dialog units to mouse position? Or have I missed something? > > > > So, the main thing is you don't want to map dialog units to pixels. In > this case, p, is a .Point object, that the OS sends as the position of > the mouse in client co-ordinates. All Windows windows have a client > area and a window area. For a window without any border the client and > window area are identical. But for windows like a dialog the two areas > are pretty different. The window area includes the title bar and the > borders. > > The clientRect() method returns the client area in a .Rect object. > Since client coordinates always are relative to 0, 0 the ~bottom member > of the Rect will be the height and the ~right member will be the width > of the client area. (The ~left and ~top will always be 0.) > > For dialogs that are not resizable, the client area will never change. > To get the 200 and 385, I believe I just printed out the client rect one > time. The code above could better be: > > if dragging then do > cr = self~clientRect > if p~x < cr~left | p~y < cr~top | - > p~x > cr~right | p~y > cr~bottom then do > > but as I said, the client rect will never change, so there is no good > reason to invoke the clientRect() method in the event handler, unless > you have a resizable dialog. Probably the better idea would be: > > ::method initDialog > expose cr > > cr = self~clientRect > ... > > ::method someMethod > expose cr > > if p~x < cr~left | p~y < cr~top | - > p~x > cr~right | p~y > cr~bottom then do > ... > > Some times mouse coordinates are in screen coordinates. For instance > getCursorPos() will return the position in screen coordinates. There > you can use screen2client(). Do not use screenToClient() as it is > inaccurate for the reasons stated above. > > mouse = .Mouse~new(self) > p = mouse~getCursorPos > > self~screen2client(p) > cr = self~clientRect > > if p~x < cr~left | p~y < cr~top | - > p~x > cr~right | p~y > cr~bottom then do > -- The cursor is currently over my > -- client area. > ... > > -- > 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 > Oorexx-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-users ------------------------------------------------------------------------------ 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 Oorexx-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-users
