Writing simple GUI - yet another GEM demo coding in C
Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Writing simple GUI - yet another GEM demo coding in C
Background Information
I have written a FD utility to analyze the protection mechanism used on diskettes (see http://www.atari-forum.com/viewtopic.php?f=47&t=9012 ) and now I want to add it a basic GUI. The application is written in C and therefore the GUI need to be written in C.
I am not a GUI person and when I need to build a simple user interface under Windows I use GUI generator. Therefore I naively thought that a Resource Construction Set programs, in conjunction with AES library, would provide this capability for the Atari environment! But after a little bit of lecture I have quickly realized that a RCS program only builds a resource tree and that you need to write all the GEM code in order to use it! Therefore even for a simple GUI it looks like you need to get a minimum knowledge about GEM (VDI / AES / GEMDOS …). For information I found a program called Visual Assembler 4.0 that seems to be a GUI generator but unfortunately it only works on Falcon, generates assembly code, seems very complex, and not maintained for quite some time.
Therefore I have “googled” around the Web to find documentation, tutorials, examples on how to write GEM code for a typical simple GUI.
The most relevant documents that I have found so far are:
• The C-manship by Clayton Walnum (http://cmanship.atariforge.org/ ) is a popular and excellent GEM programming tutorial for Atari originally published in ST Log magazine. You can find it in HTML, HYP, and it comes with sources.
• The Atari Compendium (http://cd.textfiles.com/ataricompendium/ ) provides a lot of background information on GEM. I prefer the PDF version which is easier to read offline than the HTML. Note that the PDFs are protected and you need to do some work to print them.
• Very good set of articles in ST-Magazine (http://www.abandonware-magazines.org/af ... .php?mag=6 ) # 77-80 as well as #81-93 by Claude Attard. But sorry in French only
• Article in START Magazine (http://www.atarimagazines.com/start ) vol1 #2
• Articles in ST-LOG Magazine (http://www.atarimagazines.com/st-log/ ) #34 & #35b
• “Le livre du GEM” Micro-Application (GEM programmer’s Guide – Abacus) (http://letotd.free.fr/livres.htm ) goes into a lot of details and is very good as a reference but IMHO it miss practical basic examples.
• The Professional GEM series by Tim Oren publish by Antic Publishing http://removers.free.fr/wikipendium/wak ... ngArticles
• AES and VDI quick reference books in Hypertext (.hyp) format (comes with sources) by Clayton Walnum http://dev-docs.atariforge.org/html/search.php?find=_q . This is an excellent reference and if you develop on PC use WinGuide program. (Note that I found some errors in the description of the parameters).
• DR Programmer’s guide for VDI and AES. http://dev-docs.atariforge.org/html/search.php?find=_o
• …
I have also found several libraries that are supposed to help or replace GEM:
• e_gem.220 extended GEM: Apparently very powerful (used for example by the Zorg editor) but seems complex, has not been maintained for years, and is documented in German
• BIG : Written by Claude Attard – The latest known release is 2.01 but I could not found it! However the v1.7 Is easy to find.
• EASY_GEM (seems like a very nice and powerful lib and is maintained. See http://membres.lycos.fr/eazygem/EZ_GEM.htm )
• Windom 2 (http://windom.sourceforge.net/). Huge and powerful lib but targeted mainly for Mint?
• …
For RSC construction I have found the following program:
• Lattice C: Wercs (basic but do the job)
• Resource Master 3.65 (German http://www.ardisoft.de/Download/rsm365d.zip and English http://homepage.ntlworld.com/derryck123/ddp/rsm364.lzh ). Looks powerful but I could not make it work! When in good mood the program displays unreadable Graphics but most of the time the program simply crashes (tested on Steem and on an Atari Ste). I have tried it with many different configurations and TOS versions but none of them works. I even tried to run the program under Mint with XAES but still crashes. If somebody knows a working version or what is needed to make it work I would be interested.
• Interface 2.33 - German/English/French. ftp://kurobox.serveftp.net:3021/program ... trface.zip http://www.hadley.de/ ftp://gem.win.co.nz/hall/tos_206/intrface.zip seems to be a reasonable RCS.
• And miscellaneous: RCSView 1.14 (German/English), ORCS (German), InterRCS viewer, GEM RCS 2.3 GNU, …
As you can see, it is relatively easy to find a lot of useful information and programs! Actually this is even too much information !!! So I have focused mainly on publications from Clayton Walnut and Claude Attard (see above references) as well as the Compendium for reference.
To get some basic knowledge I have decided to build several small demo programs that, when combined, will have all the features required by the GUI of my final application. I propose to document, and publish these demo programs so that hopefully they can be useful for others in the same situation. In return I expect to get feedback about what I am doing wrong so I can update the demos accordingly.
Note : I will try to use unambiguous and easy to read code with many comments and relatively classic coding presentation. I would prefer to avoid too many debates around C itself so we can concentrate on the GEM issues, but of course any comment is welcome.
First of all I would like to know if there is any interest for this project before I invest time. Based on feedback I will see how far I will go.
If there is interest, I may continue by publishing the final program: My floppy disk Protection ANalyZER (PANZER) based on my low level floppy disk library. As already mentioned this program is somewhat described in the protection document that I wrote some time ago (and still under development)… But this is another story…
If this sounds interesting in the next message I will describe the development environment as well as some of the initial requirements for the demo programs.
I have written a FD utility to analyze the protection mechanism used on diskettes (see http://www.atari-forum.com/viewtopic.php?f=47&t=9012 ) and now I want to add it a basic GUI. The application is written in C and therefore the GUI need to be written in C.
I am not a GUI person and when I need to build a simple user interface under Windows I use GUI generator. Therefore I naively thought that a Resource Construction Set programs, in conjunction with AES library, would provide this capability for the Atari environment! But after a little bit of lecture I have quickly realized that a RCS program only builds a resource tree and that you need to write all the GEM code in order to use it! Therefore even for a simple GUI it looks like you need to get a minimum knowledge about GEM (VDI / AES / GEMDOS …). For information I found a program called Visual Assembler 4.0 that seems to be a GUI generator but unfortunately it only works on Falcon, generates assembly code, seems very complex, and not maintained for quite some time.
Therefore I have “googled” around the Web to find documentation, tutorials, examples on how to write GEM code for a typical simple GUI.
The most relevant documents that I have found so far are:
• The C-manship by Clayton Walnum (http://cmanship.atariforge.org/ ) is a popular and excellent GEM programming tutorial for Atari originally published in ST Log magazine. You can find it in HTML, HYP, and it comes with sources.
• The Atari Compendium (http://cd.textfiles.com/ataricompendium/ ) provides a lot of background information on GEM. I prefer the PDF version which is easier to read offline than the HTML. Note that the PDFs are protected and you need to do some work to print them.
• Very good set of articles in ST-Magazine (http://www.abandonware-magazines.org/af ... .php?mag=6 ) # 77-80 as well as #81-93 by Claude Attard. But sorry in French only
• Article in START Magazine (http://www.atarimagazines.com/start ) vol1 #2
• Articles in ST-LOG Magazine (http://www.atarimagazines.com/st-log/ ) #34 & #35b
• “Le livre du GEM” Micro-Application (GEM programmer’s Guide – Abacus) (http://letotd.free.fr/livres.htm ) goes into a lot of details and is very good as a reference but IMHO it miss practical basic examples.
• The Professional GEM series by Tim Oren publish by Antic Publishing http://removers.free.fr/wikipendium/wak ... ngArticles
• AES and VDI quick reference books in Hypertext (.hyp) format (comes with sources) by Clayton Walnum http://dev-docs.atariforge.org/html/search.php?find=_q . This is an excellent reference and if you develop on PC use WinGuide program. (Note that I found some errors in the description of the parameters).
• DR Programmer’s guide for VDI and AES. http://dev-docs.atariforge.org/html/search.php?find=_o
• …
I have also found several libraries that are supposed to help or replace GEM:
• e_gem.220 extended GEM: Apparently very powerful (used for example by the Zorg editor) but seems complex, has not been maintained for years, and is documented in German
• BIG : Written by Claude Attard – The latest known release is 2.01 but I could not found it! However the v1.7 Is easy to find.
• EASY_GEM (seems like a very nice and powerful lib and is maintained. See http://membres.lycos.fr/eazygem/EZ_GEM.htm )
• Windom 2 (http://windom.sourceforge.net/). Huge and powerful lib but targeted mainly for Mint?
• …
For RSC construction I have found the following program:
• Lattice C: Wercs (basic but do the job)
• Resource Master 3.65 (German http://www.ardisoft.de/Download/rsm365d.zip and English http://homepage.ntlworld.com/derryck123/ddp/rsm364.lzh ). Looks powerful but I could not make it work! When in good mood the program displays unreadable Graphics but most of the time the program simply crashes (tested on Steem and on an Atari Ste). I have tried it with many different configurations and TOS versions but none of them works. I even tried to run the program under Mint with XAES but still crashes. If somebody knows a working version or what is needed to make it work I would be interested.
• Interface 2.33 - German/English/French. ftp://kurobox.serveftp.net:3021/program ... trface.zip http://www.hadley.de/ ftp://gem.win.co.nz/hall/tos_206/intrface.zip seems to be a reasonable RCS.
• And miscellaneous: RCSView 1.14 (German/English), ORCS (German), InterRCS viewer, GEM RCS 2.3 GNU, …
As you can see, it is relatively easy to find a lot of useful information and programs! Actually this is even too much information !!! So I have focused mainly on publications from Clayton Walnut and Claude Attard (see above references) as well as the Compendium for reference.
To get some basic knowledge I have decided to build several small demo programs that, when combined, will have all the features required by the GUI of my final application. I propose to document, and publish these demo programs so that hopefully they can be useful for others in the same situation. In return I expect to get feedback about what I am doing wrong so I can update the demos accordingly.
Note : I will try to use unambiguous and easy to read code with many comments and relatively classic coding presentation. I would prefer to avoid too many debates around C itself so we can concentrate on the GEM issues, but of course any comment is welcome.
First of all I would like to know if there is any interest for this project before I invest time. Based on feedback I will see how far I will go.
If there is interest, I may continue by publishing the final program: My floppy disk Protection ANalyZER (PANZER) based on my low level floppy disk library. As already mentioned this program is somewhat described in the protection document that I wrote some time ago (and still under development)… But this is another story…
If this sounds interesting in the next message I will describe the development environment as well as some of the initial requirements for the demo programs.
- Mug UK
- Administrator
- Posts: 12170
- Joined: Thu Apr 29, 2004 7:16 pm
- Location: Stockport (UK)
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
There is always interest - Nyh is probably the best person for 'C' brain-picking if you get stuck. I'm sure the Ictari disk magazines had a 'C' course and, if I can find them all, the ST Club magazine had a few articles on GUI coding in 'C'. Go for it ...
Main site: www.mug-uk.co.uk - digging up bits from my past: Atari ST, ZX Spectrum, Sega 8-bit (game hacks) and NDS (ripping guides). I host a C64 Radio Show for a mate, Max Hall via www.chipsidshow.co.uk
I develop a free Word (for Windows) add-in for Word 2007 upwards. A toolbox that will allow power Word users to fix document errors. You can find it at: mikestoolbox.co.uk
I develop a free Word (for Windows) add-in for Word 2007 upwards. A toolbox that will allow power Word users to fix document errors. You can find it at: mikestoolbox.co.uk
Re: Writing simple GUI - yet another GEM demo coding in C
I think that for writing code for GUI, actually AES you need not VDI and even GEMDOS, but AES function calls.
Myself did not programmed in C, only in ASM, but it changes not requirements.
With about some 20 AES functions is possible to make decent GUI. Of course, every beginning is hard, but later it can go fast.
Myself did not programmed in C, only in ASM, but it changes not requirements.
With about some 20 AES functions is possible to make decent GUI. Of course, every beginning is hard, but later it can go fast.
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
Yep it was a little bit hard at the begining but now I start to like it !!!ppera wrote:Of course, every beginning is hard, but later it can go fast.
Ok so lets continue ...
Development Environment
All my developments for Atari are done on PC with the following environment:
- • For writing source code I use Visual C++ 2008 Express Edition (this is free from MS http://www.microsoft.com/express/vc/ ). I know that a lot of people don’t like MS but I have used this environment many years for my job and therefore I am familiar with it. It provides a powerful text editor, with browser for functions/variables, online help, etc. But my favorite feature is the intellisense technology that automatically displays all the parameters when you type a function (even from TOS, AES, VDI) or shows you all the members of a structure, etc… I also use it to compile the source code to quickly catch incorrectly typed code. To get all the benefit of intellisense and in order to compile correctly you need to copy the AES.H, VDI.H and TOS.H files to the VC++ include directory.
• The sources are maintained under a very nice and free revision control application: CS-RCS (http://www.componentsoftware.com/Csrcs/ )
• For documentation purpose I use the fabulous doxygen : free at (http://www.stack.nl/~dimitri/doxygen/ )
• This result in a very complete html documentation. This can further be processed with the free HTML Help workshop to produce one compiled and compressed html file (.chm). Another alternative is to use Acrobat Pro for importing all the HTML into one PDF documents.
• The Code is compiled on a PC running Steem emulator with the Pure C compiler (note that I have Pure C in German, English and French). Historically I have been using Lattice C to compile all my programs on Atari. But I have not been able to compile and link the GEM code I wrote with Lattice. I guess that my main problem is the lack of documentation for version 5.60. When linking for a specific application it is hard to guess what .o startup file and what .lib library should be used among the zillion of provided files with no intuitive name! Another problem is that I really prefer the GEM headers from Pure C that, for example, uses union for object dependant members. Therefore I have switched to Pure C (English version). I must admit that the more I use it the more I like it, as it comes with a reasonable debugger and on line help.
• I did not expect problems for building resource trees but unfortunately I am running into a lot of problems in this area! Originally I wanted to use RM3.64 that seems to be the most powerful editor but, as already mentioned, I have never been able to have it run for more than a few minutes (I should say seconds!). Therefore for building the resource files I use Interface 2.33. It did work well for quite some time but apparently it does not like one of my form that uses FTEXT object where it crashes with Steem?! So as a last resort in specific cases I use WERCS from Lattice. It is the most basic of all but at least it does not crash!
• Most of the test are done under Steem (I now use the Pure C debugger but I still need to learn a lot about it) and finally on real Atari platform. The Atari is a STe model equipped with 4Mb RAM and connected to a SatanDisk. Therefore the information is transferred directly from the PC onto an SD card, and then the SD card is plugged into the SatanDisk for usage on the Atari.
Initial description of the required features:
- 1. The application should be menu driven: This means an application with a menu bar that has several menus titles each of them having several entries. Some items may need to be checked marked, some may be enabled or disabled, and some can have hotkeys (aka keyboard shortcut). Example:
2. The application may use different Forms/Dialogs. These forms are used mainly to set the different options of the program. Therefore the forms should have the standard capability to display/enter strings, radio buttons for exclusive choices, option buttons, etc.… Dialog/Forms can also be used to display simple results:
3. Most application uses several alerts. This can be simple alert (with displayed text in the source code) or more sophisticated one that allow to translate text to any languages directly in the resource file
4. The application may use file selectors to open files to read or write.
5. Most graphical application requires one or several windows to display results. The Windows may need to have title, status line, scrolling bar(s), resizer, closer, etc.… Therefore all sorts of events should be supported as well as multiple windows refresh support.
6. We also need to provide the capability to edit the content of a window. For example a window that displays the content of a buffer using HEX and ASCII representation (with both representations updated in real time during editing). Positioning of the cursor on the character, to be edited, can be done directly by clicking it with the mouse. Alternatively the direction keys can be used to move the cursor from its current position to adjacent one (up, down, left, right, home, …).
7. Potentially the application may need to use non blocking forms (form in a window - this may be detailed later): This is a very nice feature but the resulting code seems to be relatively complex.
8. What else??
To demonstrate all these features I propose first to write two very basic demos:
- • One demo with menus and dialog boxes. List of features:
o For menu: check mark on/off, entry enable/disable, key accelerator, multiple menus, and variable menus…
o For Forms: selectable button, radio button, edit fields, usage of sliders, non terminating button for immediate update of fields…
• One for drawing multiple windows:
o Graphic/Text windows, all type of events should be handled including all “arrows” events, and correct generic redraw (requires usage of function pointers) of many overlapping windows… Capability to select character in a window and to modify its content?
And finally the third demo could be a very basic hexadecimal editor. The goal is not to write a fancy editor but to put all the “pieces together” to demonstrate most basic GEM features. Feature s may look like:
- • From the file menu (or KB accelerator) we can open a file using a file selector
• The content of the file is displayed in a window in both binary and ASCII formats.
• Several files can be open at the same time each in a separate window (this will demonstrate the code necessary for correctly handle the redraw event).
• Usage of forms to setup some options (e.g. hex/dec display for address …).
• Usage of customizable alerts to signal to the user that something goes wrong.
• Capability to position and move a cursor with the mouse and direction keys.
• Capability to modify the displayed buffer by entering modification in Hexa or ASCII at the cursor position
• Capability to write back the resulting buffer.
• …
Visit *** http://info-coach.fr/atari ***
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
For documentation I have used quite a lot the AES and VDI reference please refer to http://www.atari-forum.com/viewtopic.php?f=16&t=14494 to get them. They are in hyp format and are very helpful using WinGuide on PC.
However for the c-manship book from Clayton Walnut hyp format is a real pain and hard to read (see http://www.atari-forum.com/viewtopic.ph ... it=manship ). I have therefore converted the first 26 chapters (all the book except the final example program doc) in a nice PDF document. This was a lot of work but now you can read or print the book.
Attached is the book in PDF enjoy
While we are on the topic of documentation:
Does anybody knows if the AES / VDI / TOS have been documented using Doxygen ???
As you may know doxygen is a very nice tool to document sources. Therefore I have taken the Borland/PureC header files and "doxygenized" them so they can be cross referenced with documentation of my demo programs and whaooo it is great as it cross reference all the calls, etc. For test purpose I have documented the VDI control functions as an example
However for the c-manship book from Clayton Walnut hyp format is a real pain and hard to read (see http://www.atari-forum.com/viewtopic.ph ... it=manship ). I have therefore converted the first 26 chapters (all the book except the final example program doc) in a nice PDF document. This was a lot of work but now you can read or print the book.
Attached is the book in PDF enjoy
While we are on the topic of documentation:
Does anybody knows if the AES / VDI / TOS have been documented using Doxygen ???
As you may know doxygen is a very nice tool to document sources. Therefore I have taken the Borland/PureC header files and "doxygenized" them so they can be cross referenced with documentation of my demo programs and whaooo it is great as it cross reference all the calls, etc. For test purpose I have documented the VDI control functions as an example
You do not have the required permissions to view the files attached to this post.
Last edited by DrCoolZic on Thu Sep 25, 2008 10:03 pm, edited 2 times in total.
Visit *** http://info-coach.fr/atari ***
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
OK you must say all this is nice but this is only blabla.
So lets go to the first piece of code !!!
Short Program Description
This demonstration program shows the basic programming of GEM to display menus and forms.
First I have designed two menus and 2 forms using the interface V2.30 program and the result is stored in the gdemo1.rsc resource file The detail of the actions for constructing this file are not described here, but the RSC file with the accompanying gdemo1.hrd and gdemo1.h files are provided as part of this release.
The application starts by an initialization of GEM. This is done through a generic routine gem_init() that can be reused in any GEM application.
The application has two possible menus (one short and one long) that can be loaded dynamically Using two menus from a single resource file presents some specific problems. The problems and associated solutions are described in the run_app() routine.
Some entries in the menus are used to demonstrate the capability to:
The program also processes the Keyboard entries. For demo purpose the received character and the state of the control keys are displayed on the screen. Then the program checks if the typed key combination matches an hotkey (Aka keyboard accelerator) using the generic function find_hotkey().
Here we try to avoid some common mistakes for finding hotkeys:
The program has the capability two display two forms:
- The first form is very classic: It uses radio buttons, several selections fields, several text inputs, and several buttons (see image). We do a special processing on two buttons, which are placed under
the value text to allow to dynamically increase the digit above when we click on these button with the mouse. The form exit when the OK or CANCEL button are depressed and the values of the different field are displayed using a form_alert. - The second form demonstrates the usage of sliders inside a form (see image). The two sliders in the form operates like sliders in a Window: If the left button of the mouse is clicked on top of the "slider" the slider "ghost image" follow the cursor until the mouse button is released (see image).
The two boxes at each end of the horizontal slider's box are used to decrease or increase the position of the slider by a small amount. Clicking on each side of the slider (inside the parent box) decrease or increase the slider position by a larger amount (as in a "Window’s slider"). To test the generic functions we have also a vertical slider with two button to increase and decrease, but I did not implement the capability to click above or below the slider. It is also possible to enter the position of the sliders and for the horizotal slider its
size. When the Update button is clicked the sliders size and positions are updated accordingly. For each of the operations described above some generic
functions are provided and they can be reused in any application (they are described in in detail in generic.h)
On exit we remove the menu from the screen and we call the generic function gem_exit() that take care of releasing all the resources used by the application.
OK Now the real thing
The file gdemo1.zip contain the source, resource, and executables. To compile the source you need PureC (comes with the .prj file)
All the documentation has been prepared using doxygen and you will find it in html.zip and the compiled version in gdemo1-chm.zip. For html unziping should create an html directory and just open the index.html file. You will see that doxygen does a very good job at providing all sort of useful information. If you are on a PC you can also use the .chm file (the equivalent in MS compiled format).
As you will see in the source there are two .c file: the generic.c file as the name indicates contains generic routines that you can probably re-use in any project without modification and the main.c contain code specific to this demo.
For the next code: the multiple windows demo you will have to wait as I have only started to code it.
Please fill free to send feedback as this is the goal of the game !!!
Jean
So lets go to the first piece of code !!!
Short Program Description
This demonstration program shows the basic programming of GEM to display menus and forms.
First I have designed two menus and 2 forms using the interface V2.30 program and the result is stored in the gdemo1.rsc resource file The detail of the actions for constructing this file are not described here, but the RSC file with the accompanying gdemo1.hrd and gdemo1.h files are provided as part of this release.
The application starts by an initialization of GEM. This is done through a generic routine gem_init() that can be reused in any GEM application.
The application has two possible menus (one short and one long) that can be loaded dynamically Using two menus from a single resource file presents some specific problems. The problems and associated solutions are described in the run_app() routine.
Some entries in the menus are used to demonstrate the capability to:
- - dynamically load another menu
- checkmark entries
- Enable or disable entries.
The program also processes the Keyboard entries. For demo purpose the received character and the state of the control keys are displayed on the screen. Then the program checks if the typed key combination matches an hotkey (Aka keyboard accelerator) using the generic function find_hotkey().
Here we try to avoid some common mistakes for finding hotkeys:
- - We first have to read correctly the typed character for different KB configuration (international kb) and therefore the key value returned by evnt_multi cannot be used directly. For example:
- key = $1E01 for CTRL-A on an English keyboard and
- key = $1001 for CTRL-A on a French keyboard
- Then we have to look for customized hotkey in the menu. For that matter we look for a possible hotkey in all menu entries. As we want to provide the capability for the users to customize their
hotkeys based on their local language, we do not hard code the hotkey detection in the source but we check the hotkeys directly in the menu entries from the resource tree. For example we may want to retrieve:
- "Close ^C" in English and
- "Fermer ^F" in French.
The program has the capability two display two forms:
- The first form is very classic: It uses radio buttons, several selections fields, several text inputs, and several buttons (see image). We do a special processing on two buttons, which are placed under
the value text to allow to dynamically increase the digit above when we click on these button with the mouse. The form exit when the OK or CANCEL button are depressed and the values of the different field are displayed using a form_alert. - The second form demonstrates the usage of sliders inside a form (see image). The two sliders in the form operates like sliders in a Window: If the left button of the mouse is clicked on top of the "slider" the slider "ghost image" follow the cursor until the mouse button is released (see image).
The two boxes at each end of the horizontal slider's box are used to decrease or increase the position of the slider by a small amount. Clicking on each side of the slider (inside the parent box) decrease or increase the slider position by a larger amount (as in a "Window’s slider"). To test the generic functions we have also a vertical slider with two button to increase and decrease, but I did not implement the capability to click above or below the slider. It is also possible to enter the position of the sliders and for the horizotal slider its
size. When the Update button is clicked the sliders size and positions are updated accordingly. For each of the operations described above some generic
functions are provided and they can be reused in any application (they are described in in detail in generic.h)
On exit we remove the menu from the screen and we call the generic function gem_exit() that take care of releasing all the resources used by the application.
OK Now the real thing
The file gdemo1.zip contain the source, resource, and executables. To compile the source you need PureC (comes with the .prj file)
All the documentation has been prepared using doxygen and you will find it in html.zip and the compiled version in gdemo1-chm.zip. For html unziping should create an html directory and just open the index.html file. You will see that doxygen does a very good job at providing all sort of useful information. If you are on a PC you can also use the .chm file (the equivalent in MS compiled format).
As you will see in the source there are two .c file: the generic.c file as the name indicates contains generic routines that you can probably re-use in any project without modification and the main.c contain code specific to this demo.
For the next code: the multiple windows demo you will have to wait as I have only started to code it.
Please fill free to send feedback as this is the goal of the game !!!
Jean
You do not have the required permissions to view the files attached to this post.
Visit *** http://info-coach.fr/atari ***
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
Another piece of Documentation!
Pure C is extremely nice but most doc are in German. However there is a an English overview that gives a lot of useful information.
I have reformated the document (originally in text format) so it looks a bit nicer and I have generated a PDF file for it.
If you are not very familiar with Pure C this is a must read.
Pure C is extremely nice but most doc are in German. However there is a an English overview that gives a lot of useful information.
I have reformated the document (originally in text format) so it looks a bit nicer and I have generated a PDF file for it.
If you are not very familiar with Pure C this is a must read.
You do not have the required permissions to view the files attached to this post.
Visit *** http://info-coach.fr/atari ***
Re: Writing simple GUI - yet another GEM demo coding in C
See here for the official (and current) AES and VDI doc: http://arnaud.bercegeay.free.fr/gemlib/ ... dules.htmlDrCoolZic wrote: Does anybody knows if the AES / VDI / TOS have been documented using Doxygen ???
Re: Writing simple GUI - yet another GEM demo coding in C
Nice thread, DrCoolZic . I hope that some people will get inspiration from this and we will see new programmers and SW for old machine and GEM ... 

- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
This is great but I am a little bit confuse about gemlib. How does it relate to the "old" DR GEM ?jfl wrote:See here for the official (and current) AES and VDI doc: http://arnaud.bercegeay.free.fr/gemlib/ ... dules.htmlDrCoolZic wrote: Does anybody knows if the AES / VDI / TOS have been documented using Doxygen ???
From what I understand GEM is somewhere on the ROM of our ST machine and the AES/VDI/TOS libs provided with Pure C are just "wrappers" to make life of C programmers easier. So what about gemlib ? Of course I should take time to read about it ... but I'd like to know: is it also some sort of wrapper to the GEM on ROM or is it a remplacement lib bypassing completely the ROM (and therefore independant of the version of the TOS) ?
By the way did you looked at my new version of c-manship doc ?
Visit *** http://info-coach.fr/atari ***
Re: Writing simple GUI - yet another GEM demo coding in C
Hi,
There is a GFA Basic editor/interface piece of software!
Thanks,
Bye
There is a GFA Basic editor/interface piece of software!
Thanks,
Bye
Atari STFM 512 / STe 4MB / Mega ST+DSP / Falcon 4MB 16Mhz 68882 - DVD/CDRW/ZIP/DAT - FDI / Jaguar / Lynx 1&2 / 7800 / 2600 / XE 130+SD Card // Sega Dreamcast / Mega2+CD2 // Apple G4
http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records
http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
I found a bug in generic.c
When finding an hotkey I generate a message that I send with appl_write(). Of course the message should be MN_SELECTED and not MU_MESAG
This is corrected in this new release 1.1 - PS I did not regeneerate the documentation
When finding an hotkey I generate a message that I send with appl_write(). Of course the message should be MN_SELECTED and not MU_MESAG
This is corrected in this new release 1.1 - PS I did not regeneerate the documentation
You do not have the required permissions to view the files attached to this post.
Visit *** http://info-coach.fr/atari ***
Re: Writing simple GUI - yet another GEM demo coding in C
i'm not sure how this program works but i found on net today. seems to convert rsc files into c code , at least thats what i made of it from the description..
gui or not gui its definitilly worth a look
charles
gui or not gui its definitilly worth a look
charles
You do not have the required permissions to view the files attached to this post.
The radioactive half-life : )
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
Thanks Charles I know about this program and yes it converts an resource tree into C code. This is interesting to see how a resource tree looks like once converted to C (also it is rather unreadable!). However it is not recomended to do so because you loose all the benefits of a resource file. For example the resource file allow easy translation of a program to a foreign language or allow to modify the look of the dialog boxes all that without rewriting a line of code. Obviously once converted to C any modification need to be done in C!charles wrote:i'm not sure how this program works but i found on net today. seems to convert rsc files into c code , at least thats what i made of it from the description.. gui or not gui its definitilly worth a look
charles
Jean
Visit *** http://info-coach.fr/atari ***
Re: Writing simple GUI - yet another GEM demo coding in C
I'VE DONE THIS IN SOME CODE JUST SO OTHERS DON'T TRY TO STEAL VALUABLE WORK.
I'LL ADMIT WHEN I HAVE LIKE 100+ OBJECTS IN A FORM IT TAKES A LONG TIME TO MAKE ON RESOURCE EDITOR AND I'M NOT COMFORTABLE WITH JUST ANYBODY WALKING OFF EASILLY WITH THIS WORK..
SO EMBEDDING IT IN THE PROGRAM IS SIMPLE SOLUTION.
CHARLES
I'LL ADMIT WHEN I HAVE LIKE 100+ OBJECTS IN A FORM IT TAKES A LONG TIME TO MAKE ON RESOURCE EDITOR AND I'M NOT COMFORTABLE WITH JUST ANYBODY WALKING OFF EASILLY WITH THIS WORK..
SO EMBEDDING IT IN THE PROGRAM IS SIMPLE SOLUTION.
CHARLES
The radioactive half-life : )
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!
- lp
- Fuji Shaped Bastard
- Posts: 2821
- Joined: Wed Nov 12, 2003 11:09 pm
- Location: GFA Headquarters
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
That's hilarious
So you are worried about someone opening up a rsc file and stealing the word "Ok" or "Cancel" from some button? OMG If on the other hand you have hundreds of custom icons (which I very much doubt), even so it's a 5 minute job to snap the screen, load the IMG file into Interface, grab the icon/crop it and bingo, it's now in my app. So you are wasting your time with such thinking. FYI, Interface will load 640x400 full snaps! All you are doing is making the program harder to maintain and translate.


So you are worried about someone opening up a rsc file and stealing the word "Ok" or "Cancel" from some button? OMG If on the other hand you have hundreds of custom icons (which I very much doubt), even so it's a 5 minute job to snap the screen, load the IMG file into Interface, grab the icon/crop it and bingo, it's now in my app. So you are wasting your time with such thinking. FYI, Interface will load 640x400 full snaps! All you are doing is making the program harder to maintain and translate.
Re: Writing simple GUI - yet another GEM demo coding in C
What are you afraid someone would do with the RSC-form they are "walking away with".....?charles wrote:I'VE DONE THIS IN SOME CODE JUST SO OTHERS DON'T TRY TO STEAL VALUABLE WORK.
I'LL ADMIT WHEN I HAVE LIKE 100+ OBJECTS IN A FORM IT TAKES A LONG TIME TO MAKE ON RESOURCE EDITOR AND I'M NOT COMFORTABLE WITH JUST ANYBODY WALKING OFF EASILLY WITH THIS WORK..
SO EMBEDDING IT IN THE PROGRAM IS SIMPLE SOLUTION.
CHARLES
Writing an application that can make use of such a form would *definately* take much, much, much, much longer time than creating that RSC-form in the editor one hundred times. Trying to protect the RSC file for such reasons seems rather pointless to me, especially since we now have reached 2008 and the number of hijacked software projects on the Atari platform isn't exactly skyrocketing these days..

Btw, writing in CAPITALS equals shouting and comes off pretty.. ehm.. ..loud, so you might want to avoid that.
Regards,
/Joakim
Re: Writing simple GUI - yet another GEM demo coding in C
He should avoid programming altogether, seeing the amount of utter nonsense he writes .GokMasE wrote:Btw, writing in CAPITALS equals shouting and comes off pretty.. ehm.. ..loud, so you might want to avoid that.
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
Demo Example 2
Introduction
The code presented here demonstrates the basic usage of GEM windows
Program Organization
The code is separated into two main groups:
A window with sliders should be considered as a "window" on a bigger document. This allow to work with 'virtual documents' much larger than the screen. For example you may have a virtual document with a size of 1000 * 1000 pixels. In the program this information is kept in the full_w (width) and full_h (height) variables of a _windes structure. A GEM window with a size of 100 * 100 pixels can be positioned to display a small portion of the virtual document. The position of the window inside the virtual document is kept in the cur_x (current x) and cur_y (current y) variables of a _windes structure. These two values can be changed by moving the horizontal and vertical sliders.
Information on how to compute the coordinate of a point:
Program Description
This program is used to demonstrate the usage of multiple windows on the screen. Up to seven windows can be open at the same time. We define 3 "types" of windows:
Introduction
The code presented here demonstrates the basic usage of GEM windows
Program Organization
The code is separated into two main groups:
- - Application specific code : All the application specific code is located in the main.c file.
- Generic independent code : All other files are generic functions that can be reused. Everything has been done to maximize the reusable code for example the usage of a pointer to a drawing function allow to have a generic code for the window redraw.
A window with sliders should be considered as a "window" on a bigger document. This allow to work with 'virtual documents' much larger than the screen. For example you may have a virtual document with a size of 1000 * 1000 pixels. In the program this information is kept in the full_w (width) and full_h (height) variables of a _windes structure. A GEM window with a size of 100 * 100 pixels can be positioned to display a small portion of the virtual document. The position of the window inside the virtual document is kept in the cur_x (current x) and cur_y (current y) variables of a _windes structure. These two values can be changed by moving the horizontal and vertical sliders.
Information on how to compute the coordinate of a point:
- - Current position of Window in the Virtual Document (WDx, WDy)
- Current position of Window in the Screen (WSx, WSy)
- Point in the Virtual Document (VTx, VTy)
- Point in a Window (Wx , Wy) = (VTx + WDx, VTy + WDy)
- Point in the screen (X, Y) = (VTx + WDx - WSx, VTy + WDy - WSy)
Program Description
This program is used to demonstrate the usage of multiple windows on the screen. Up to seven windows can be open at the same time. We define 3 "types" of windows:
- - Graphical windows: A window of the size of the desktop that contains some graphical elements.
- Text window: A window that display 50 lines of text.
- File text window: We first ask user for an ascii file, then we read it into a buffer and we display the content in a window.
- - main() initializes the application with gem_init(), runs the application with run_gui() and terminates the application when run_gui() returns by calling gem_exit().
- run_gui() loads the resource file, gets the addresses of the different trees, loads the menu and goes to process the events with process_events(). When this last function returns the menu is unloaded and the procedure returns.
- process_events() processes the keyboard and messages events until user request to terminate the application. For the keyboard event we only call the find_hotkey() function. For messages we call the process_messages() function.
- process_messages function() processes the menu events by calling the process_menu_events() and the windows events by calling either generic or specific windows functions. Please refer to the code for more information on these different windows functions.
You do not have the required permissions to view the files attached to this post.
Visit *** http://info-coach.fr/atari ***
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
The above code examples cover about 95% of what I need to know for writing my final application.
As it does not look like there is too much interest for this subject, I will drop for the time beeing my proposal to write an example of an hexadecimal editor.
I am waiting for eventual feedback on errors or better way to do things.
Thanks
Jean
As it does not look like there is too much interest for this subject, I will drop for the time beeing my proposal to write an example of an hexadecimal editor.
I am waiting for eventual feedback on errors or better way to do things.
Thanks
Jean
Visit *** http://info-coach.fr/atari ***
Re: Writing simple GUI - yet another GEM demo coding in C
Better way? AssemblerDrCoolZic wrote: I am waiting for eventual feedback on errors or better way to do things.

Better is for people who started with ASM, as me.
Feedback here? People is too busy guessing game titles

- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
Yes I know I should probably invest some time in learning 68K ASM.ppera wrote:Better way? AssemblerDrCoolZic wrote: I am waiting for eventual feedback on errors or better way to do things.Just kidding...
Better is for people who started with ASM, as me.
Feedback here? People is too busy guessing game titles
I have done lots of assembly specially when I was doing some hw development. Started with the 85/Z80 ASM then moved to the 8051/2 ASM then to ASM86... But when I moved to sw development most of my important work were done in C++ and going back to ASM seems to excessive (going back to C was OK).
ASM makes a lot of sense for the kind of development you are doing on HD driver where performance is an issue.
However for what I am doing I am not sure it would be too usefull. For my complete FDC library I have only one piece of maybe 50 lines of ASM because here performance and precise control was important, but for the rest C is just fine!
Visit *** http://info-coach.fr/atari ***
Re: Writing simple GUI - yet another GEM demo coding in C
So do you think your generic code is starting to resemble the libraries and 'wrappers' you mentioned earlier? Thanks for this, I'll have a look with a view to coding some GEM stuff in C.DrCoolZic wrote:Program Organization
The code is separated into two main groups:
- - Application specific code : All the application specific code is located in the main.c file.
- Generic independent code : All other files are generic functions that can be reused. Everything has been done to maximize the reusable code for example the usage of a pointer to a drawing function allow to have a generic code for the window redraw.
The zzSoft assembly book deals with some GEM stuff, but when you're coding in assembly it gets a bit too long and painful to comfortably pick things up. It seemed like a huge amount of work to deal with GEM tbh.
tá'n poc ar buile!
- DrCoolZic
- Fuji Shaped Bastard
- Posts: 2270
- Joined: Mon Oct 03, 2005 7:03 pm
- Location: France
- Contact:
Re: Writing simple GUI - yet another GEM demo coding in C
Actually this is a good question! Probably we could answer yes, however this was not the goal. But for sure I will definitively use this functions as part of my GEM developments. It came out naturally there are some code that can obviously always be the same so why rewrite it ?Desty wrote:So do you think your generic code is starting to resemble the libraries and 'wrappers' you mentioned earlier? Thanks for this, I'll have a look with a view to coding some GEM stuff in C.

Visit *** http://info-coach.fr/atari ***
Re: Writing simple GUI - yet another GEM demo coding in C
I agree completely! The nice thing about writing your own library from scratch is that you come to understand how it all works, and then use your library to simplify and speed up your coding in future.DrCoolZic wrote:But for sure I will definitively use this functions as part of my GEM developments. It came out naturally there are some code that can obviously always be the same so why rewrite it ?
Much better than struggling to use some confusing library which you don't understand, and certainly not how it works underneath.

tá'n poc ar buile!