1. DOS GUI
I've been thinking about how my (still varporware) Dos32Lib, and decided
that I had gotten *way* off base with WinMan.
Sure, it's neat to be able to maximize, minimize and drag a window
around on the screen. But is it really necessary? After all, in DOS
mode, there is only going to be one application running. So it may as
well fill the whole screen.
This is the approach that Scitech took with their MGL GUI - it runs in
full screen mode. I was disappointed when I initially saw that. But
now, it makes a lot of sense.
So I've decided that's the approach that I should be taking with
DOS32Lib. You'll get a menu bar at the top of the screen, and a status
line at the bottom. The rest of the screen will be occupied by the
primary window.
Any objections/comments to this approach?
-- David Cuny
2. Re: DOS GUI
Cuny, David wrote:
>
> I've been thinking about how my (still varporware) Dos32Lib, and decided
> that I had gotten *way* off base with WinMan.
>
> Sure, it's neat to be able to maximize, minimize and drag a window
> around on the screen. But is it really necessary? After all, in DOS
> mode, there is only going to be one application running. So it may as
> well fill the whole screen.
>
> Any objections/comments to this approach?
>
Unless there are really good reasons for limiting things, please don't.
I can see that it would be handy to be able to "iconize" certain
portions of
a program while working on others. One example: look up a product in a
product
database, fill out an order blank in another. Nice to be able to click
on the
product icon and take a peek at the data, then back to the order.
Even though nothing is technically "running" behind that icon, the user
won't know or care. In fact, that was the next thing I was planning to
add
to my Windoz pkg. It just seems neater to have the icons off to the
side,
on the "desktop" rather than having them cover up part of the "work"
screen.
Regards,
Irv
3. Re: DOS GUI
Irv wrote:
> Unless there are really good reasons for limiting things, please
> don't. I can see that it would be handy to be able to "iconize"
> certain portions of a program while working on others. One
> example: look up a product in a product database, fill out an
> order blank in another. Nice to be able to click on the product
> icon and take a peek at the data, then back to the order.
Thanks for the feedback; I'll keep it in mind. I still have this
modal/nonmodal thing to fix in Win32Lib first, anyway.
-- David Cuny
4. Re: DOS GUI
>Date: Tue, 18 Aug 1998 18:19:57 -0400
>Reply-To: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
>From: Irv <irv at ELLIJAY.COM>
>Subject: Re: DOS GUI
>To: EUPHORIA at LISTSERV.MUOHIO.EDU
>
>Cuny, David wrote:
>>
>> I've been thinking about how my (still varporware) Dos32Lib, and
decided
>> that I had gotten *way* off base with WinMan.
>>
>> Sure, it's neat to be able to maximize, minimize and drag a window
>> around on the screen. But is it really necessary? After all, in DOS
>> mode, there is only going to be one application running. So it may as
>> well fill the whole screen.
>>
>> Any objections/comments to this approach?
>>
>Unless there are really good reasons for limiting things, please don't.
>I can see that it would be handy to be able to "iconize" certain
>portions of
>a program while working on others. One example: look up a product in a
>product
>database, fill out an order blank in another. Nice to be able to click
>on the
>product icon and take a peek at the data, then back to the order.
>Even though nothing is technically "running" behind that icon, the user
>won't know or care. In fact, that was the next thing I was planning to
>add
>to my Windoz pkg. It just seems neater to have the icons off to the
>side,
>on the "desktop" rather than having them cover up part of the "work"
>screen.
>
>Regards,
>
>Irv
>
Hmm... Fairly easy, albeit. the Desktop, to what it seems, is nothing
more than an undraggable window (i'll check later if I am right) All you
have to do is have buttons on the desktop that hides/unhides windows.
Kewl Idea. I'll try that. (BTW, I am now really able to code it now, as
I have written some notes on procedures, colors, justification, etc.
after printing out 3,500+ lines of code! =)
BTW, anyone want those notes? (I still have to figure out what Listbox
and GlyphBtn do...)
-- "LEVIATHAN"
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
5. Re: DOS GUI
bonn ortloff wrote:
>
> ><snip>///
>
> Hmm... Fairly easy, albeit. the Desktop, to what it seems, is nothing
> more than an undraggable window (i'll check later if I am right) All you
> have to do is have buttons on the desktop that hides/unhides windows.
> Kewl Idea. I'll try that. (BTW, I am now really able to code it now, as
> I have written some notes on procedures, colors, justification, etc.
> after printing out 3,500+ lines of code! =)
>
> BTW, anyone want those notes? (I still have to figure out what Listbox
> and GlyphBtn do...)
>
Assuming you are talking about my Windoz pkg:
Yer right, the Desktop is just a "bitmap object" that can be placed on
the screen,
but is declared at such a low level that it can't do much else. Like
move,
get focus, etc.
GlyphBtn is just a button with a user-written grzphic (one declared as a
Euphoria sequence like you would use in polygon()...
color, fill, {{x1,y1},{x2,y2},{x3,y3}}
Handy for things like check marks in checkboxes, other simple graphics.
You already figured out what ListBox does: nothing. Sadly, that is one
control I haven't gotten around to writing. Maybe this week.
I'd love to have a copy of those notes!
Irv
6. Re: DOS GUI
Irv wrote:
> Unless there are really good reasons for limiting things, please
> don't. I can see that it would be handy to be able to "iconize"
> certain portions of a program while working on others. One
> example: look up a product in a product database, fill out an
> order blank in another. Nice to be able to click on the product
> icon and take a peek at the data, then back to the order.
David, I agree with you. IMHO you should keep things simple.
There are other and, I think, better ways to do a look up and
get help, for instance. I would do this with function keys and
saving and redisplaying parts of the screen. And, above that,
if we=B4re speaking of getting input from the keyboard, then a
mouse is barely needed at all.
Ad
7. Re: DOS GUI
Ad Rienks wrote:
> David, I agree with you. IMHO you should keep things simple.
> There are other and, I think, better ways to do a look up and
> get help, for instance. I would do this with function keys and
> saving and redisplaying parts of the screen. And, above that,
> if we´re speaking of getting input from the keyboard, then a
> mouse is barely needed at all.
>
> Ad
Ad:
I use a keyboard, and you use a keyboard.
Unfortunately, the people who are willing to pay me money to write
programs often do not like to use a keyboard.
Perhaps they have been unduly influenced by Windows. Perhaps I am overly
fond of consuming food on a semi-regular schedule. I shouldn't let this
influence my judgement , but sometimes it does. :)
Enjoying the revitalized discussion --
Irv
8. Re: DOS GUI
Irv, you wrote:
>Ad:
>I use a keyboard, and you use a keyboard.
>Unfortunately, the people who are willing to pay me money to write
>programs often do not like to use a keyboard.
IMNSHO (in my not so humble opinion), that is very patronizing and
silly to boot. Obviously, it all depends on the context of a
particular task and its ergonomics - mainly common sense in the
overall design. For instance, if I am in an editor, or perhaps
updating and correcting entries in a form, I want to stick to my
keyboard, and keyboard 'shortcuts' are a sensible way to do it. But on
the other hand, if I am just going through a lot of menus, pushing
buttons, checking boxes etc, forget the tab, space, return and
function keys, the mouse is quicker, and I do not have to *memorize*
anything... Jiri
9. Re: DOS GUI
>Date: Wed, 19 Aug 1998 16:24:30 -0400
>Reply-To: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
>From: Irv <irv at ELLIJAY.COM>
>Subject: Re: DOS GUI
>To: EUPHORIA at LISTSERV.MUOHIO.EDU
>
>bonn ortloff wrote:
>>
>> ><snip>///
>>
>> Hmm... Fairly easy, albeit. the Desktop, to what it seems, is nothing
>> more than an undraggable window (i'll check later if I am right) All
you
>> have to do is have buttons on the desktop that hides/unhides windows.
>> Kewl Idea. I'll try that. (BTW, I am now really able to code it now,
as
>> I have written some notes on procedures, colors, justification, etc.
>> after printing out 3,500+ lines of code! =)
>>
>> BTW, anyone want those notes? (I still have to figure out what
Listbox
>> and GlyphBtn do...)
>>
>Assuming you are talking about my Windoz pkg:
>Yer right, the Desktop is just a "bitmap object" that can be placed on
>the screen,
>but is declared at such a low level that it can't do much else. Like
>move,
>get focus, etc.
>
>GlyphBtn is just a button with a user-written grzphic (one declared as
a
>Euphoria sequence like you would use in polygon()...
> color, fill, {{x1,y1},{x2,y2},{x3,y3}}
>Handy for things like check marks in checkboxes, other simple graphics.
>
>You already figured out what ListBox does: nothing. Sadly, that is one
>control I haven't gotten around to writing. Maybe this week.
>
>I'd love to have a copy of those notes!
>
>Irv
>
I noticed my notes are still quite BETA. I have to find out the Set()
for the stuff (I know so far only Text() Everythings got a set to it,
right? I just have to find out)
Here ya go, Irv. :)
-- "LEVIATHAN"
-- Begin notes
adds:
-------
Text("name","data",x1,y1,x2,y2,group#) -- What'z it say, 'cluck?
BitBtn("name",{file1.bmp, file2.bmp},x1,y1) -- Bitmap Button
Bitmap(filename,"caption",x1,y1) -- Bitmap proc
Button("name","caption",x1,y1,x2,y2) -- Text button
Checkbox ("name","caption",x1,y1,group#) -- what it says.
Label("name","caption",x1,y1,x2,y2) -- for use inside a panel only.
ListBox("name",x1,y1,x2,y2,group#) -- ?
RadioBtn("name","caption",x1,y1,group#) -- Radio Button
Scroller("name",x1,y1,x2,y2) -- Scroll bar, vert, methinx.
Edit("name","data",x1,y1,x2,y2,group#) -- field
Slider("name",x1,y1,x2,y2) -- Record scroll bar
Titlebar("name","caption",x1,y1,x2,y2) -- what it says.
GlyphBtn("name",glyph,x1,y1,x2,y2) -- ?
----------------------------------------
-- styles: -- state: -- status:
PLAIN = 0, NORMAL = 0, UNCHECKED = 0,
RAISED = 1, MAX = 1, CHECKED = 1,
RECESSED = -1, MIN = -1, DISABLED = -1,
DEFAULT = 2, ANI = 99,
BORDER = 3,
-- actions: -- other:
EXIT = -1, MODAL = 1,
NONMODAL = 0,
LOCKED = -1 -- window can't be focused
----------------------------------------
Colorz:
--------
Black = 256, Blue = 257, Green = 258, Cyan = 259, Red =
260,
Magenta = 261, dkRed = 262, ltGray = 263, dkGray = 264, ltBlue =
265,
ltGreen = 266, ltCyan = 267, ltRed = 268, mdGray = 269, Yellow =
270,
White = 271
--------------------------------------------
justification, prints, wraps:
------------------------------
'additive', e.g. fa=FBO+FIT gives you bold italics
NUL=0, -- none: surprise !
FBO=1, -- bold
FSH=2, -- shadows
FIT=4, -- italics
FUN=8, -- underline
FNN=0, -- (or NUL) no justification in either direction, '\n'
-- (new line) returns to original fx with line feed
FLN=1, -- left justified, no vertical justification
FCN=2, -- horizontally centred, no vertical justification
FRN=3, -- right justified, no vertical justification
FLC=4, -- left justified, vertically centred
FCC=5, -- centred in both directions
FRC=6, -- right justified, vertically centred
FNW=0, -- (or NUL) no wrap
FCW=1, -- char based wrap
FWW=FCW, -- word based wrap (still defaults to char wrap (again,
-- sorry, not yet implemented, perhaps next time!)
-- End. STILL BETA
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
10. Re: DOS GUI
BABOR, JIRI wrote:
>
> Irv, you wrote:
>
> >Ad:
> >I use a keyboard, and you use a keyboard.
> >Unfortunately, the people who are willing to pay me money to write
> >programs often do not like to use a keyboard.
>
> IMNSHO (in my not so humble opinion), that is very patronizing and
> silly to boot. Obviously, it all depends on the context of a
> particular task and its ergonomics - mainly common sense in the
> overall design. For instance, if I am in an editor, or perhaps
> updating and correcting entries in a form, I want to stick to my
> keyboard, and keyboard 'shortcuts' are a sensible way to do it.
You have cited exactly the situation I had in mind: the clients
_want_ (should I say, demand) to be able to click on a field
in an order form, click on a product, select some options, and
have the field filled in. Tabbing from field to field is also
available, as are "hot keys" and regular menus, but I've never
seen anyone use them efficiently for the day-to-day tasks.
Since these same people also write the checks, I consider it neither
patronising nor silly to give them what they want - just sensible.
> But on
> the other hand, if I am just going through a lot of menus, pushing
> buttons, checking boxes etc, forget the tab, space, return and
> function keys, the mouse is quicker, and I do not have to *memorize*
> anything... Jiri
Exactly. Think how much easier it is to train a new employee if all they
have to learn (about the computer) is to scroll, point and click.
This is a major consideration for a lot of businesses.
Irv
11. Re: DOS GUI
bonn ortloff wrote:
>
> I noticed my notes are still quite BETA.
>
That's pretty good, considering the software's still Alpha!
>I have to find out the Set()
> for the stuff (I know so far only Text() Everythings got a set to it,
> right? I just have to find out)
Everything (every property) can be Set, Look at the file GLOBALS.WIN.
Each slot in the generic_window_obj can be set. Not all of them are
safe to set (you wouldn't want to change an object's handle, for
example)
like this:
object win -- create a new object
win = Window("myWindow","Visible title for this window's
titlebar",x1,y1,width,height)
win = Add(win, Button("btnName","OK",x1,y1,width,height,group#)
win = Set(win,"btnName",COLORS,{FGND,BKGND,TEXT})
^win ^control ^property ^value(s)
Each call to Set looks up the control by name (btnName) and sets the
property (COLORS)
to the value {...}. The value you send depends on what the property is
supposed to
hold: COORDS and SIZE are always {x,y} for all controls, of course.
COLORS always gets a 3 value sequence. Most are explained in the
comments
in GLOBALS.WIN. The contents of DATA varies depending upon the type of
control.
It can be text or a number (boolean true/false in the case of a checkbox
or radiobutton), or something else altogether for future controls.
GROUP controls the tabbing from field to field. When it works :) the
tab key/ shift tab moves to the next/prev control in that window
which has that GROUP #. When it tabs out of the group, it returns
control to the mouse. This is awkward but necessary because, so far,
Jiri's otherwise excellent font.e does not support mouses.
Regards,
Irv
12. Re: DOS GUI
- Posted by bonn ortloff <kc7yrh at HOTMAIL.COM>
Aug 20, 1998
-
Last edited Aug 21, 1998
>Date: Thu, 20 Aug 1998 12:59:12 -0400
>Reply-To: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
>From: Irv <irv at ELLIJAY.COM>
>Subject: Re: DOS GUI
>To: EUPHORIA at LISTSERV.MUOHIO.EDU
>
>bonn ortloff wrote:
>>
>> I noticed my notes are still quite BETA.
>>
>That's pretty good, considering the software's still Alpha!
>
>>I have to find out the Set()
>> for the stuff (I know so far only Text() Everythings got a set to it,
>> right? I just have to find out)
>
>Everything (every property) can be Set, Look at the file GLOBALS.WIN.
>Each slot in the generic_window_obj can be set. Not all of them are
>safe to set (you wouldn't want to change an object's handle, for
>example)
>like this:
>object win -- create a new object
>win = Window("myWindow","Visible title for this window's
>titlebar",x1,y1,width,height)
>win = Add(win, Button("btnName","OK",x1,y1,width,height,group#)
>win = Set(win,"btnName",COLORS,{FGND,BKGND,TEXT})
> ^win ^control ^property ^value(s)
>
>Each call to Set looks up the control by name (btnName) and sets the
>property (COLORS)
>to the value {...}. The value you send depends on what the property is
>supposed to
>hold: COORDS and SIZE are always {x,y} for all controls, of course.
>COLORS always gets a 3 value sequence. Most are explained in the
>comments
>in GLOBALS.WIN. The contents of DATA varies depending upon the type of
>control.
>It can be text or a number (boolean true/false in the case of a
checkbox
>or radiobutton), or something else altogether for future controls.
>GROUP controls the tabbing from field to field. When it works :) the
>tab key/ shift tab moves to the next/prev control in that window
>which has that GROUP #. When it tabs out of the group, it returns
>control to the mouse. This is awkward but necessary because, so far,
>Jiri's otherwise excellent font.e does not support mouses.
>
>Regards,
>
>Irv
>
Yup. Basically, you only want to change the property(ies) and value(s),
and not the rest. Combining mighty.e and font.e was a hell of an idea. I
love it! (hehe... I even changed the cursor :) All you really have to do
to font.e is add the mouse code, no?
TRU Regards :)
-- "LEVIATHAN"
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
