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

Rob wrote:
> Veli-Pekka Tätilä wrote:
> There have certainly been some PPM releases in the past that didn't
> include any html docs
Yep, I recall reading something to that effect. Well, I've just updated all
PPM packages lately and now I have all the GUI docs I need. Really speeds up
navigation when you've got the HTML content locally. At least the old,
out-dated docs were very slow to access even on broadband (VDSL).

> [Talking about Layout managers]
> It's a rectangular grid. You can set column and row width/height,
> although IIRC the default is for equal-sized columns and rows
Ah, good to know the dimensions can be changed. Java's GridLayout also let's
you specify the number of rows and columns as well as the horizontal and
vertical grid gaps but that's about it. I've always thought a grid layout
would be cool for making a calculator.


>> still prefer dragging and dropping conponents in a dialog graphically.
> 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. I do have VC6 here, so I thought of
using its resource editor for the dialogs and possibly menus, too. That's
why I'd be interested in loading resource files and attaching Win32::GUI
event handlers to the loaded controls.

>> GetSystemMetrics and GetTextMetrics. Maybe these two and the related
>> functions could be used possibly by importing them using Win32::API.
> Both these functions are already available
> http://perl-win32-gui.sourceforge.net/cgi-bin/docs.cgi?doc=reference-methods#getsystemmetrics
> for now you'll need to find them from elsewhere.
Oh ok. I do have the headers so that's not an issue. I think I might be able
to create font-independent code then. But I'll keep your warnings about
remaining bugs in mind.

> [Moving onto threads]
> As I said, I can't comment on Win32::OLE <sip>
> Win32::GUI can be used in a single thread to run your gui, with other
> threads doing the work.
Again this is good news to me. Too bad I'm using OLE heavily and it won't
work with threads currently. Well, that's just how it is.

> 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. I recall reading somewhere that the behavior is emulated in
Win32 which may be slow. This is just a gut feeling, I' not a thread guru
nor hav I run the benchmarks.

[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.
Without this style they won't be part of the tab order in the dialog, at
least in the Win32 API. That is you cannot set the keybord focus to such
controls by using [shift+] tab.

While being excluded from the tab order may be desirable for some types of
controls such as group boxes, generally you should always include say
enabled check boxes, radio buttons, lists and trees in the tab order
(disabled controls are automagically excluded). If you don't, and there's no
shortcut, the keyboard user canot access that control without using a screen
reader specific mouse emulation mode. Even if a control is not in the tab
order, however, it can still receive keyboard messages provided that it has
the focus somehow.

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.

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.

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.

> If you'd be happy for me to contact you then I'd appreciate
> accessibility feedback.
I'd be glad to, as soon as you have something to test. My e-mail address is
the same as in the signature that is:

vtatila@xxxxxxxxxxxxxxxxxxxx

Probably not an issue but please don't post in HTMl as I've got
spam_Assassin set real strict.

> 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?

[clipbord bugs?]
>> use strict; use warnings;
>> use Win32::Clipboard;
>> my $clip = Win32::Clipboard->new();
>> for(;;)
>> { # Infinite loop for testing purposes.
>> $clip->WaitForChange();
>> print 'Got: ', $clip->GetText(), "\n";
>> } # for
>> prints the previous clipboard contents on the screen even if the
>> contents have not changed since the beginning <snip> seems to freeze in
>> the WaitForChange method the second time even if
>> I copy more text in the clipboard.
> It will always print the current contents of the clipboard on start-up.
Ok, seems I need to check it initially, as I wouldn't want to destroy the
user's current clipboard contents, either.

> It seems to work OK for me <snip> Perl 5.8.7(build 813),
> Win32::Clipboard v0.5101, Win98SE)
It would appear not to work for me but I've got a different setup:
-Win32::Clipboard V0.5101
-Perl 5.8.6
-Win XP SP2 Pro English

--
With kind regards Veli-Pekka Tätilä (vtatila@xxxxxxxxxxxxxxxxxxxx)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/


.

Relevant Pages

  • Re: Win32::GUI: Documentation, Layout and accessability
    ... design environment (written in Win32::GUI http://user.bahnhof.se/~johanl/perl/Loft/ ... 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. ... And cancel should be the second because most dialogs start with OK and Cancel in the very bottom in this order. ...
    (comp.lang.perl.misc)
  • Re: How to change tab order of report controls?
    ... I think the OP is referring to the tab order in design view. ... selecting of controls by name. ... > When someone generates a report, ...
    (microsoft.public.access.reports)
  • Re: Tab Order Add-In?
    ... The customer insists on seeing all the information ... Tab Order control is quite inefficient at organizing the tab ... while dragging a control or controls to the top or bottom of the ... the original positions of the controls. ...
    (comp.databases.ms-access)
  • Re: Set focus on command button
    ... SetFocus is used on forms with a Tab order; ... Controls on a worksheet doesn't behave that way, ...
    (microsoft.public.excel.programming)
  • Re: context-menu copy/paste
    ... None of the standard .NETCF controls have Clipboard support out of the box. ... TextBoxEx in the OpenNETCF SDF adds Cut Copy and Paste methods. ...
    (microsoft.public.dotnet.framework.compactframework)