Re: Win32::GUI: Documentation, Layout and accessability

Veli-Pekka Tätilä wrote:
Rob wrote:
Veli-Pekka Tätilä wrote: 

[Win32 design environments]

I've never experimented with it, but there's a Win32::GUI graphical
design environment (written in Win32::GUI <sip> http://user.bahnhof.se/~johanl/perl/Loft/

I'll give it a shot. I've also seen some XML based design tool for Win32::GUI but the name escapes me. 

WGX - http://www.numeninest.com/Perl/WGX/

[Moving onto threads] 

I found the following article very enlightening:
http://www.perlmonks.org/?node_id=288022

Thanks for pointing this out. I haven't realized interpreter based threads are this heavy. Also, it says that forking is fast but I think it is fast only in Unix. 

Correct.  Forking in windows is emulated using ithreads.

[speaking of accessibility]

have some other reports of dialog navigation (particularly 'tab' navigation) not working

In addition to any bugs in Win32::GUI, one reason might be that the person doing the code has not specified the WS_TABSTOP style for the controls.

I had a quick look at this one myself when the report was raised. It appears that either the Win32::GUI wrapper or the underlying control that is used is not honouring the WS_TABSTOP style correctly.

Maybe the Win32::GUI could add certain controls in the tab order automatically. My rationale is that these controls ought to be in the tab order in the first place and the user wouldn't have to memorize putting them there. Not being in the tab order, for something like buttons, is the exception rather than the rule.

I'll add this to my list of things to think about. My immediate reaction would be that designing an algorithm that *always* does something sensible would be hard. Such an algorithm should be looking at adding WS_TABSTOP and WS_GROUP styles.

Another thing that often goes awry is enter not being equivalent to ok and esc to cancel. But at least in the Win32::API this is a result of correct message handling and setting default buttons etc... The equivalent actions are wel documented in Win32::GUI so we've got just the lib users to blame, I guess. I cannot think of a good way to specify a default button automatically. MAybe the first inserted button in the dialog, if none is specified. And cancel should be the second because most dialogs start with OK and Cancel in the very bottom in this order. YOu can also layout buttons on the right, in which case ok is the top-most and has the cancel button below it. Or this style is expected by most users, at least.

Again, getting it right automatically would be hard, but there are some interesting ideas there.

How's the default tab order for Win32::GUI is it the insertion order? I think many graphical tools use the insertion order and thus you often get an illogical tab sequence if the designer has tweaked the controls afterwords, removing some and adding others. Programmatically, going through the controls from top to bottom, left to right and respecting group boxes could be a sufficient default.

The order is defined by the win32 api as the control creation order, which in Win32::GUI is the object creation order.

do come across any accessibility issues with Win32::GUI, please raise
bug reports through either the perl-win32-gui@xxxxxxxxxxxxxxxxxxxxx list
or the sourceforge tracker system.

Will do. I'll be lazy and ask what the subscription address is for the former? 

http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users

Regards,
Rob.
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/
.

Relevant Pages