Hi again David (and Rick, I think this may answer one of your questions
also),
Sorry I didn't think of this last night David when I was first answering:
each of the types of controls in the app reference manual has quite an array
of properties and methods which help you determine where it's placed and how
large it's area of the screen is. Each of these controls is assigned its
own window, and Vic Beckley wrote an app sometime back named "Focused Window
Detective", which provides you with some information about the window of the
currently focused control.
I modified the app slightly so it would give me screen pixel information for
the top/bottom and left/right coordinates of the window of the focused
control. I found it immediately helpful in showing me that the editbox the
XML dialog was creating for me was of 0 height! No wonder I was having such
difficulties.
It's not going to tell you what you should do, but just by adding the lines
below to Vic's app I think you'll find his app becomes very helpful in
knowing how your dialog control fits. You could also go further and add
info about the dialog window itself to make sure your control hasn't
partially moved out of the main dialog.
Also, the editbox control has methods which will tell you the character
index number which begins each line (so for instance, it may tell you that
line 2 starts with character 21, and so you know on average you are only
getting an editbox 20 characters wide), and so you could also add this
information. The method is "CharFromLine". (you have to find the topic
"control" and open it up in the manual, then you can find a subtopic named
"control types" and open it, and finally you can find "editbox" and open it
up to see its properties and methods).
The only slightly confusing part of what I'm suggesting is that WE has 3
forms of position measurement: the dialog units you were asking about, the
screen pixel coordinates, and window pixel coordinates (which are relative
to the top left corner of the overlap window). You sometimes must convert
from one form to another, as you are only given one set of coordinates and
you may want another. As you see in the lines below, you are given window
pixel coordinates as part of a window object, but I wanted to know the
absolute screen pixel coordinates location, so I made use of methods which
convert the window units to screen units.
If you open up the "Focused Window Detective" .vbs file, below is a few
lines you can look for, and you can see the few lines I added to demonstrate
how easy it is to get additional information displayed:
If myWindow.Parent.Title <> "" Then wInfo = wInfo + myStrings("ParentTitle")
& vbSpace & myWindow.Parent.Title & vbCrLf
If myWindow.Style <> "" then wInfo = wInfo + myStrings("Style") & vbSpace &
myWindow.Style & vbCrLf
' added by Chip
wInfo = wInfo & "Top" & vbSpace & myWindow.rectangle.screenRectangle.top &
vbCrLf
wInfo = wInfo & "Bottom" & vbSpace &
myWindow.rectangle.screenRectangle.bottom & vbCrLf
wInfo = wInfo & "Left" & vbSpace & myWindow.rectangle.screenRectangle.left &
vbCrLf
wInfo = wInfo & "Right" & vbSpace & myWindow.rectangle.screenRectangle.right
& vbCrLf
' end added by Chip
It's a very nice app and easy to figure out what it's doing and make
changes.
Hth,
Chip
From: Chip Orange [mailto:lists3...@comcast.net]
Sent: Sunday, October 07, 2012 8:02 PM
To: gw-scripting@gwmicro.com
Subject: RE: XML question - How many units?
Hi David,
I absolutely agree with you; if there's room for improvement in the WE
scripting design, the XML dialogs and the problem you mention are certainly
one of the most obvious places to start.
I had a dialog within the last few weeks which was generating an editbox
(even though set to multiple lines) which was only displaying roughly 3
words per line. It was very frustrating. I was only able to determine this
by use of the mouse cursor.
I could not get the XML to make it any larger without guessing at dialog
unit numbers, which I was reluctant to do.
I don't know for certain that my solution is any better, but what I did was
to add the controls to the dialog which allowed it to be resized; and then I
tried to define all my groups and my editbox using "fill" as the width or
height as appropriate.
Finally, I added a maximize command in the dialog event handler when the
dialog is being created (for the dialog's window).
This solved my issue and caused an editbox which seemed to display a large
amount of text, as judged with the mouse cursor.
I'm not sure what would make this better for blind developers, but perhaps a
parameter for editboxes which allowed us to specify a minimum width and
minimum height in characters would be a good start. The XML dialog routines
could then try to create an editbox as close to our specified size of the
time as was possible, as opposed to whatever they are doing right now (which
I'm guessing is just filling up the group).
HTH,
Chip
From: David [mailto:eleph...@tele2.no]
Sent: Thursday, October 04, 2012 7:29 AM
To: gw-scripting@gwmicro.com
Subject: XML question - How many units?
When creating an XML dialog, holding an Edit box, I want to enter a number
for the hight and width. Big question is, how high can that number be, and
still fit inside a window on a normal basis. I.e, is there any way to
calculate this, or is it a simple hit and miss. Specially when designing
dialogs as a blind person, I find it hard to know whether a line or text
block will fit into the window. My experience has been, that WE will read
the whole line, even if the line is being cut off on the screen. Could there
have been a method or something in the GWToolkit, that would take a string,
and return an approximate number for the hight or width. I am not too
familiar with the screen units being used in this regard, but my guess is
that one unit might vary, depending on current font and size. Am I right on
this one? If so, I do understand there might be a challenge in giving the
exact number for the maximum hight and width to be used for a given text to
be displayed in an Edit box, but that is why, I ask that the calculation at
least could give some kind of an approximate - or suggested number. I found
little help in browsing the reference manual on the matter, but maybe I was
overlooking something. Or, does anyone of you blind app developers, have a
good way of testing whether a dialog is properly designed.
Thanks for any feedback.
