From: <vt...@ma...> - 2005-12-06 12:15:18
|
Hi, My first post here, so here's a brief intro. I'm rather new to Win32::GUI= =20 but have built simple GUIs in Java's Swing. I've also programmed the raw=20 WIn32 API a bit in C but am not terribly familiar with laying out text in= a=20 dialog, having done that in VC's dialog editor when-ever I can. I should=20 probably also mention I'm legally blind and have to access Windows with a= =20 screen reader (the latest beta of Dolphin Supernova). Though using the mo= use=20 is possible for me with magnification, I'd like to design my GUIs to be=20 keybord and screen reader accessible. ADditionally, I'd rather keep the m= y=20 GUI control size, resolution and DPI independent knowing that my current=20 Windows appearance is not exactly standard. Win32::GUI seems the only Perl GUI library that is fully screen reader an= d=20 keybord accessible so the choice of GUI lib is easy for me. By the way, m= y=20 Win32::GUI version installed with PPM appears to be 1.02 (looking inside= =20 the PM file). Enough intros, I guess. I've got some questions on laying out text. THis = is=20 fairly basic stuff and has probably been asked a zillion times so feel fr= ee=20 to point me to earlier posts. I've read the FAQ and the tutorial, as well= as=20 browsing the function reference, a bit. However, I have only done very=20 little coding in Win32::GUI so far. My question is, how do I know the width and height I should give to contr= ols=20 in order to make all text fit and also have nice spacing between the=20 controls themselves? Petzold uses the font properties average width and=20 height plus external leading in his Windows books. I reckon this will be just fine for labels and I can get this info by askin= g=20 it from a font object. But howabout say check boxes? I reckon you'll have to leave space for the= =20 check mark and focus rectangle, too, so how do I know how much space thes= e=20 will take exactly? I guess I could initially set up a check box with no=20 label and then compare its height and width against the check box's clien= t=20 area to get this information. Does this also work for the more complex=20 controls say tree and list views or text bocxes? But I'm still worried about the spacing. By looking at dialogs magnified,= =20 I've concluded that there's more than just a bit spacing between vertical= ly=20 layed out check boxes. What do the Win32 interface guidelines say about=20 this? I know Visual Studio let's you situate check boxes all too close to= =20 each other and think this might also apply to Win32::GUI if I'm not caref= ul=20 enough. Lastly, I've been pondering coordinates and spacing too. It would appear = to=20 me the Win32::GUI Windows use client coordinates but do the dialogs use=20 dialog units, then? The Win32 API has a function GetDialogBaseUnits but I= =20 have not seen it imported in Win32::GUI at all. I'd also like to know what would be a good strategy for laying out contro= ls=20 vertically or horizontally in the dialog or near the dialog borders? If I= 'd=20 like to lay out buttons at the bottom or right, for instance, should I us= e=20 percentages of dialog height or width or is there a better way? Java's=20 layout managers do a wonderful job and I know there's that grid layout fo= r=20 Win32::GUI, but I've yet to check it out. Further more, how much spacing=20 should go between dialog push buttons? I know VC's graphical dialog edito= r=20 adjusts these things automatically, mostly, so I have never had to=20 consciously think of the spacing that much. I know there are some fairly advanced tools for WIn32::GUI but I have not= =20 truely dived into them. Ironically, the graphical GUI editor is not reall= y=20 keyboard (tab, shift+tab) or screen reader accessible, to the extent that= =20 the Visual Studio 6 dialog editor is. Also, writing GUIs in XML seems nic= e=20 but it would appear it doesn't make laying out the GUI components much=20 easier, apart from automatic resizing. --=20 With kind regards Veli-Pekka T=E4til=E4 (vt...@ma...) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/=20 |
From: Robert M. <rm...@po...> - 2005-12-06 23:49:04
|
Hi, Nice to see you here after our exchange in comp.lang.perl.misc. Veli-Pekka T=E4til=E4 wrote: > By the=20 > way, my Win32::GUI version installed with PPM appears to be 1.02=20 > (looking inside the PM file). 1.03 is available for download from SourceForge and is now in=20 ActiveState repository for perl 5.8 > But I'm still worried about the spacing. By looking at dialogs=20 > magnified, I've concluded that there's more than just a bit spacing=20 > between vertically layed out check boxes. What do the Win32 interface=20 > guidelines say about this? 'Official' Microsoft recommendations: http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dnwue/= html/ch14e.asp > Lastly, I've been pondering coordinates and spacing too. It would appea= r=20 > to me the Win32::GUI Windows use client coordinates but do the dialogs=20 > use dialog units, then? The Win32 API has a function GetDialogBaseUnits= =20 > but I have not seen it imported in Win32::GUI at all. Win32::GUI currently uses pixel positioning exclusively. Top-level=20 windows in screen-coordinates and child windows in client coordinates.=20 No use of dialog units currently, and you are correct that=20 GetDialogBaseUnits is not currently implemented. The following perl function can be used to do the conversion: ## Dialog Base Units to pixels # - object is a Win32::GUI::Window # - direction is one of: # Horizontal: W(idth), X, L(eft), R(ight) # Vertical : H(eight), Y, T(op), B(ottom) # - dbu is the dialog units to convert # Returns btu converted to pixels # Returns undef when in error sub convDBU { my ($object, ,$direction, $dbu) =3D @_; my %font_metrics =3D Win32::GUI::Font::GetMetrics($object->GetFont()); if (index("WXLR",$direction) !=3D -1) { my $dbuX =3D $font_metrics{-avgwidth}; $dbu =3D ($dbuX * $dbu) / 4; } elsif (index("HYTP",$direction) !=3D -1) { my $dbuY =3D $font_metrics{-height}; $dbu =3D ($dbuY * $dbu) / 8; } else { return undef; } # use int, as we need something that is always too small return int($dbu); } Regards, Rob. |