On Sat, Feb 9, 2013 at 2:39 AM, Staffan Tylen <staffan.ty...@gmail.com>wrote:
> Thanks for your comments on this, Mark. I'll just need to rethink my user
> interface, no big deal.
>
Actually, after thinking about it last night, I thought there is really no
reason why I couldn't get the .Keyboard class started and enhance it later.
I had already implemented a getAsyncKeyState method and tested it:
C:\work.ooRexx\other\feature.requests\update.listView>simpleListView.rex
Column click 2 control key pressed 0
Column click 2 control key pressed 1
Column click 1 control key pressed 1
Column click 0 control key pressed 1
Column click 1 control key pressed 1
Column click 2 control key pressed 1
Column click 2 control key pressed 0
Column click 1 control key pressed 0
Column click 1 control key pressed 1
Column click 0 control key pressed 1
Column click 1 control key pressed 1
Column click 1 control key pressed 1
Column click 1 control key pressed 1
> Knowing nothing about the Windows API you mention, my immediate reaction
> is that if Windows generates these events (including mouse events?)
> regardless of which dialog control or even dialog window has focus, methods
> or event handlers could maybe be part of the WindowsBase or the
> WindowsExtensions class,
>
I do not claim to be very knowledgeable in Object Orientated design, but I
think that is a mistake. Anything that I say following is not something I
thought up, it is stuff I've read or heard others say regarding objects
that I agree with.
A common mistake when starting out with object design is to have one huge
monolithic object that does everything. This was the mistake that the
original designers made with ooDialog. They had just one huge object, the
dialog. Everything was done through the dialog object. Even having dialog
control objects with their own methods was added later in the development
cycle, after several iterations.
That's why you have methods of the dialog object like addComboEntry(),
getCurrentListIndex(), moveControl(), etc..
At the highest level of abstraction, a control's position is a property of
the control. Changing its position (moving) is something that the control
itself does, something the control knows how to do. The dialog itself can
not change the control's position and has nothing to do with moving it.
Rather than asking the dialog to move a control, which even at a lower
level of abstraction it can not do, it is better to simply tell the control
to move itself
Likewise, the currently selected index is something the list box knows. It
is a property of the list box. The dialog object has no knowledge of what
index is currently selected in the list box. Rather than asking the dialog
what the selected index of a list box is, you should ask the list box
directly.
Really, if the implementation of the dialog object was correct, when you
asked the dialog what the index is, it should say "I don't know." When I
ask my nephew where his brother is, he always says, "I don't know." So, I
never ask him any more. Instead, I text his brother and ask him directly.
A key press is not something a window does, it is not a property of a
window. It is not even something a window knows. Even at a low level of
abstraction, you can not query a window and find out what the state of the
control key is.
The thing that does know the state of a key, is the keyboard. So at a high
level of abstraction it makes sense to ask the Keyboard object what the
state of one of its keys is. It makes even more sense when you realize
that even at a low level of abstraction that is actually what happens.
When you use the GetAsyncKeyState() API, the device driver for the
keyboard is what is queried.
or perhaps better as a separate Keyboard mixin class so that the methods
> are there ready to use.
>
I don't think it even makes sense to make the Keyboard class a mixin class.
The WindowBase mixin class is, almost, ideal. Every method and attribute
of the class is an action that every window can do or a property of ever
window. I say almost because even there a few things crept in that don't
belong. For instance the initCode is an attribute of the WindowBase class.
Dialog controls, which are windows, do not have an initCode. The
initCode is unique to a dialog. And it is not even a property of a dialog
window, it is a property of the Rexx dialog object.
In Windows, everything is a window, so it makes sense to have a WindowBase
class that can be mixed into to other objects, that are all windows. The
dialog is a window, the list-view is a window, the push button is a window,
etc., etc.. It doesn't make sense to mix in keyboard actions and
properties to any of the current objects in ooDialog.
Anyhow, I'm going to add a Keyboard class, with just a few methods for
4.2.2 and plan on enhancing the class later. One method is the
getAsyncState(). Here is the code the produced the output I showed:
::method onColumnClick unguarded
use arg id, col, listView
say 'Column click' col 'control key pressed'
.Keyboard~getAsyncState(.VK~CONTROL)
The above is wrapped, the say statement is all one line. You pass in the
key you are querying and the method returns true if the key is down, false
if it is up.
--
Mark Miesfeld
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
