1. DOS GUI
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Aug 18, 1998
- 521 views
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
- Posted by Irv <irv at ELLIJAY.COM> Aug 18, 1998
- 506 views
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
- Posted by David Cuny <dcuny at LANSET.COM> Aug 18, 1998
- 488 views
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
- Posted by bonn ortloff <kc7yrh at HOTMAIL.COM> Aug 19, 1998
- 544 views
>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
- Posted by Irv <irv at ELLIJAY.COM> Aug 19, 1998
- 498 views
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
- Posted by Ad Rienks <Ad_Rienks at COMPUSERVE.COM> Aug 19, 1998
- 508 views
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
- Posted by Irv <irv at ELLIJAY.COM> Aug 19, 1998
- 491 views
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
- Posted by "BABOR, JIRI" <J.Babor at GNS.CRI.NZ> Aug 20, 1998
- 506 views
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
- Posted by bonn ortloff <kc7yrh at HOTMAIL.COM> Aug 20, 1998
- 496 views
>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
- Posted by Irv <irv at ELLIJAY.COM> Aug 20, 1998
- 500 views
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
- Posted by Irv <irv at ELLIJAY.COM> Aug 20, 1998
- 484 views
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
- 523 views
- 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