Re: GUIS - DOS and otherwise
Hi, All.
[Control Text Attributes]
People have been asking for the ability to change fonts family, size and
styles of control labels in Win32Lib. I've mentioned this several times,
but I'll say it again:
I still have NO idea how to do this. If someone does, please clue me in!
I understand how to change the attributes for dialogs, but Win32Lib
builds the windows dynamically - it doesn't use real dialogs. I was
thinking of breaking the controls into two parts: a static label (the
text), and the control portion. But I don't know how to change the
attributes of a static label any more than for any other control.
The only option I can think of at this point is to take over the display
of the text by hand - something that I would prefer not to do.
Can anyone help?
[DOS GUI Features]
My goals for Dos32Lib are fairly modest: support the basic Win32Lib API
in DOS. A bit more functionality than my Dialog program, perhaps - but
not that far from it.
I *don't* intend to:
- invent a new GUI
- write a Win95 replacement
- add features unlikely to be used
I don't see that much serious demand for a DOS GUI - most people
demanding the features that Irv has been alluding to will be in Win95,
not DOS. After all, Dos32Lib won't even be able to use a printer.
[How GUI is Windoz?]
Just a few critical notes (sorry) about Windoz. I should preface them
with the comments that
(1) there is nothing in the current design that prevents these things
from being corrected, and (2) yes, I know: it's just an *alpha* release.
Anyhoo, Windoz is permeated with modality. All this goes against the
whole concept of a graphical interface - to *avoid* modes.
Windoz is either in Mouse mode or Text Edit mode (perhaps "Keys" mode is
a better name), and these modes are diametrically opposed - virtually
every feature in one mode is absent in the other.
In Mouse mode, keys are ignored, and there is no concept of focus. You
can click and drag, but the behavior is inconsistant from one control to
the next. For example:
1. Click the window control button in the upper left corner, and the
button depresses. Keeping the mouse button pressed, drag the mouse off
the button and release the mouse button. Release the mouse button, and
the window control button remains depressed, instead of popping back up.
--- side note
The button retains the "pressed" attribute. For example, do the above
procedure to a dialog, and close it. Open the dialog again, and the
control button is still drawn as depressed.
--- end side note
2. Now click the OK command button, and the button depresses. Keeping
the mouse button pressed, drag the mouse off the command button. The
command button correctly pops up. But (keeping the mouse button pressed)
drag it back onto the command button - and it does not depress again.
--- side note
While I'm on the topic, if you click on the label of a control, it has
no effect. For example, with the checkbox control:
[ ] Foo
you should be able to click on the label ("Foo"), as well as the check
box graphic.
-- end side note
The other major modality is the SLE Text Edit mode. When you enter Text
Edit mode, the mouse disappears entirely, so it *only* accepts
keystrokes.
To exit the Text Edit mode, you need to know the magic key to press
(escape), or Tab past the SLE fields, and mouse (again, magically)
appears as Mouse mode is entered.
The Text Edit code isn't really well integrated into Windoz. It
overwrites the SLE's bottom border, and if you get to the end of the
SLE, it overwrites the right border.
In Text Edit mode, Windoz suddenly acquires a concept of focus, and the
The Tab and Shift+Tab keys work. But the keys have two different
functions: Navigation, and Exit Mode. If there is next/prior field is an
SLE, you are navigated to that field. But if it is not, you are booted
out into Mouse mode again. Same key, same control, same mode - two
different behaviors.
Pressing the right mouse button pops up an attribute browser - but you
can't enter edit any of the controls. Apparently, they are read-only,
although there is nothing to clue the user that this is the case. The
controls *look* just the same as editable text.
The latest demo is even more modal. You can't do anything while the
program is drawing - you have to press a key to exit that mode. Dragging
the window to another position gives away the trick of the Draw mode -
it writes to the screen where the window is *positioned*, not actually
*onto* the window. So if you move the window, you lose the drawing.
OK, end of complaints.
-- David Cuny
|
Not Categorized, Please Help
|
|
