1. Win32Lib Changes
I've decided that I need to add the shift key parameters to the key and
mouse events. This will break a lot of code, but it's something that I
should have done a long time ago anyway.
I could either go with the Visual Basic form of:
onMouse( integer event, integer shift, integer x, integer y )
or like this:
onMouse( integer event, integer x, integer y, integer shift )
Is there any preference to the order of parameters? Obviously, the onKey
events will follow the same format.
Additionally, I'm pretty tempted to fold the onKeyDown/Press/Up into a
single routine, like so:
onKey( integer event, integer keyCode, integer shift )
in the same way that I did to make onMouse a single function. Is this a bad
idea? Would people prefer that I split the onMouse trap back into
onMouseDown/Move/Up as it is in Visual Basic?
Part of the problem is that Window's handling of keys isn't very portable,
and it's a bit irritating. All keys are passed as raw scan codes to
onKeyDown/Up, while onKeyPress sees ANSI keys - but no 'special' keys. Argh.
My personal preference would be something like this:
onKey( integer event, integer keyCode, integer shift )
where 'event' would either be KeyUp/KeyDown, and keyCode would be the ANSI
value of a key (if it were a normal key), or a key code representing a
'special' key. I may hack it myself, but I'm a bit worried about
international keyboards.
Comments?
Thanks!
-- David Cuny
2. Re: Win32Lib Changes
On Fri, 17 Sep 1999, Cuny, David wrote:
> I've decided that I need to add the shift key parameters to the key and
> mouse events. This will break a lot of code, but it's something that I
> should have done a long time ago anyway.
<snip>
>
> Comments?
>
Well, since nobody else has commented yet, I'll put in my few pennies. I
don't really mind how you do it as long as it's consistent. I don't mind
handling all mouse/key input in single routines and IMO it looks cleaner
to do it that way. As far as what order the parameters should be, I
believe that's a call the developer should make. I'll just change my code
accordingly. (On the other hand, people converting from VB might be
happier if you did it the VB way... just a thought.)
BTW, I'm working more with XPM files and I'm wondering about the global
function 'createXpm' in xpm.e. Would you be willing to change that like
you changed 'createDIB', i.e. createXpm( sequence outFile, sequence euBmp)?
This is certainly non-critical but it's just more consistent.
Thanx,
Brian
3. Re: Win32Lib Changes
Brian K. Broker wrote:
> I don't mind handling all mouse/key input in single routines and
> IMO it looks cleaner to do it that way.
I'll do this if I can figure out how to code it cleanly.
> As far as what order the parameters should be, I
> believe that's a call the developer should make.
My tendancy is to tack it on the end, but there's no special logic to that.
Unless people speak up, that's the way it's going to be in the next release.
> BTW, I'm working more with XPM files and I'm wondering
> about the global function 'createXpm' in xpm.e. Would you
> be willing to change that like you changed 'createDIB', i.e.
> createXpm( sequence outFile, sequence euBmp)?
Good idea. The next release has also integrated the XPM routines into
Win32Lib, and make the transparent color a lot simpler to deal with.
Thanks!
-- David Cuny
