Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

EMS

Status
Not open for further replies.

qbasicking

Programmer
Aug 19, 2001
628
US
I plan to use EMS for my GUI, but I have only used it a few times before, I have the code for it, but I have a few questions about it:
Could it be any way harmful to the computer, or to the workings of Windows? (Windows will most likely be running in the background)
 
An NT class Windows will not crash at all, and in all likelihood if you misplace a pointer while running under Windows 9x, you will simply crash another program that is running. You could also crash the system, but it would not be permanent (you could just reboot). The chance of actually damaging anything is very slight, especially if you make sure your EMS routines are very safe before you start using them (e.g., wrap everything up in some [tt]SUB[/tt]s that make sure you only use valid already-allocated memory addresses and stuff).

However, my recommendation if you want to design your own GUI system is to use an object-oriented language. Graphical interfaces are inherently object-oriented -- a window, a scrollbar, an input box, a button, a text label, a menu, a menu item, etc., they are all distinct and self-contained, and they also all share certain functionality (e.g., they all have a coordinate on the screen and a size, and they can all be asked to draw themselves; in addition, most of them store a string of some kind, for instance the text on a button, in an input box, or in the titlebar of a window). You could use a language like Java or C# to design the interface in a platform-independent fashion, using a bitmap buffer as your drawing target. Alternately, you could extend the existing GUI system with your own classes with their own custom rendering methods. Either way, it's much more powerful an approach than using QB for a GUI.

That said, designing a proper GUI in QB is a good challenge for any programmer, especially since you have to work around QB's lack of objects and lack of references (you could use an array as an object pool and use indices as references, but that still doesn't generically handle containers). It's something I might try myself if I ever had the time :)
 
Cardinal II has no object handling (but ti does draw itself) - it took up to much memory, I want to use EMS memory to load the applications into, it will be faster than the virtual memory that I am using now

People say that GUIs are extremely hard to make - I find that it is just that so few people have tried them or stuck with them - I have an incredibly powerful GUI as do many people that I have seen
 
But because it's not object-oriented, it doesn't run itself. You can't just add a bunch of controls to a form. You can't just ask an object to draw itself. Building up forms dynamically is difficult and requires container structures outside of the parent object, etc. It is my belief that any good GUI should be able to run itself after a one-time configuration pass. QuickBASIC can't even do callbacks, making this impossible.
 
It works alright, because I just loop the code for the buttons. I tell it to draw the buttons once, then it loops and checks for the buttons to be pressed

This is some .cex code

NEWPAGE|test
WINDOW|Test Window|10|10|200|200
BUTTON|Button|10|10|80|25|0|test
DO
CLICK|10|10|80|25|THEN
BUTTON|Button|10|10|80|25|1|test
END|IF
LOOP|UNTIL|KEY$|<>|

I want to load the entire program into memory, but some of my apps are getting pretty huge
 
Status
Not open for further replies.

Similar threads

  • Locked
  • Question
ems
Replies
0
Views
17

Part and Inventory Search

Sponsor

Back
Top