Writing simple GUI - yet another GEM demo coding in C

C and PASCAL (or any other high-level languages) in here please

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Wed Sep 24, 2008 1:43 pm

Background Information
I have written a FD utility to analyze the protection mechanism used on diskettes (see 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.

User avatar
Mug UK
Administrator
Administrator
Posts: 11210
Joined: Thu Apr 29, 2004 7:16 pm
Location: Stockport (UK)
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby Mug UK » Wed Sep 24, 2008 4:25 pm

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 ...
My main site: http://www.mug-uk.co.uk - slowly digging up the bits from my past (and re-working a few): Atari ST, Sega 8-bit (game hacks) and NDS (Music ripping guide).

I develop a free Word (for Windows) add-in that's available for Word 2007 upwards. It's a fix-it toolbox that will allow power Word users to fix document errors. You can find it at: http://www.mikestoolbox.co.uk

ppera

Re: Writing simple GUI - yet another GEM demo coding in C

Postby ppera » Wed Sep 24, 2008 4:38 pm

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.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Thu Sep 25, 2008 6:13 am

ppera wrote:Of course, every beginning is hard, but later it can go fast.

Yep it was a little bit hard at the begining but now I start to like it !!!

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 some GUI Requirements

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??

Initial Description of the Demo’s Applications

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?

The goal of these two demos is first to experiment with the different GEM calls and to start to build a set of routines that can be reused in the final application. For that matter the source will be organized into generic and application specific code to maximize reusability.
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.
    • …

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Thu Sep 25, 2008 6:43 am

For documentation I have used quite a lot the AES and VDI reference please refer to 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 viewtopic.php?f=70&t=14616&start=0&st=0&sk=t&sd=a&hilit=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.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Thu Sep 25, 2008 7:20 am

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
menu.jpg


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 menu is also used to display two differents forms, to display information, and to exit. The entry marked ??? shows what is happening when an entry not yet handled (during debug) is selected.

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 nice side effect is that the code takes care automatically of \b ALL possible accelerators placed in the resource file. This allow the user to make a \b full \b customization of the resource and to change hotkeys or even add new ones in any menu entry.

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.
form1.jpg

- The second form demonstrates the usage of sliders inside a form (see image).
form2a.jpg

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).
form2b.jpg

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.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Thu Sep 25, 2008 12:22 pm

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.
You do not have the required permissions to view the files attached to this post.

User avatar
jfl
Atari Super Hero
Atari Super Hero
Posts: 829
Joined: Tue Jul 18, 2006 10:55 pm
Location: Liège, Belgium
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby jfl » Thu Sep 25, 2008 4:20 pm

DrCoolZic wrote:Does anybody knows if the AES / VDI / TOS have been documented using Doxygen ???

See here for the official (and current) AES and VDI doc: http://arnaud.bercegeay.free.fr/gemlib/ ... dules.html
Jean-François
GEMDict – GEMClip

ppera

Re: Writing simple GUI - yet another GEM demo coding in C

Postby ppera » Thu Sep 25, 2008 4:36 pm

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 ... :D

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Thu Sep 25, 2008 8:58 pm

jfl wrote:
DrCoolZic wrote:Does anybody knows if the AES / VDI / TOS have been documented using Doxygen ???

See here for the official (and current) AES and VDI doc: http://arnaud.bercegeay.free.fr/gemlib/ ... dules.html

This is great but I am a little bit confuse about gemlib. How does it relate to the "old" DR GEM ?
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 ?

User avatar
nativ
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4087
Joined: Mon Jul 30, 2007 10:26 am
Location: South West, UK

Re: Writing simple GUI - yet another GEM demo coding in C

Postby nativ » Fri Sep 26, 2008 8:38 pm

Hi,
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

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Sun Sep 28, 2008 3:01 pm

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
You do not have the required permissions to view the files attached to this post.

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2061
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby charles » Sun Sep 28, 2008 3:33 pm

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
You do not have the required permissions to view the files attached to this post.
atari is my lifestyle,not a hobby.
HOLD ON ! ! !,
Im printing unreadable characters ...!

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Sun Sep 28, 2008 5:51 pm

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

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!
Jean

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2061
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby charles » Sun Sep 28, 2008 6:10 pm

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
atari is my lifestyle,not a hobby.
HOLD ON ! ! !,
Im printing unreadable characters ...!

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2257
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby lp » Sun Sep 28, 2008 8:41 pm

That's hilarious :!: :lol:

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.

User avatar
GokMasE
Captain Atari
Captain Atari
Posts: 182
Joined: Sun Mar 02, 2003 11:16 pm
Location: Sweden
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby GokMasE » Sun Sep 28, 2008 8:44 pm

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


What are you afraid someone would do with the RSC-form they are "walking away with".....?

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

User avatar
jfl
Atari Super Hero
Atari Super Hero
Posts: 829
Joined: Tue Jul 18, 2006 10:55 pm
Location: Liège, Belgium
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby jfl » Sun Sep 28, 2008 9:11 pm

GokMasE wrote:Btw, writing in CAPITALS equals shouting and comes off pretty.. ehm.. ..loud, so you might want to avoid that.

He should avoid programming altogether, seeing the amount of utter nonsense he writes .
Jean-François
GEMDict – GEMClip

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Mon Sep 29, 2008 11:19 am

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:
    - 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.

Size of the different pieces of a window system
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)
- In other word to convert from a point in the virtual document to a point in the physical screen we have to "add the position" of the windows compared to the virtual document and to "subtract the position" of the window compared to the physical screen.

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.
Windows-type.jpg


Program is organized as follow:
    - 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.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Mon Sep 29, 2008 11:36 am

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

ppera

Re: Writing simple GUI - yet another GEM demo coding in C

Postby ppera » Mon Sep 29, 2008 12:50 pm

DrCoolZic wrote:I am waiting for eventual feedback on errors or better way to do things.


Better way? Assembler :mrgreen: Just kidding...
Better is for people who started with ASM, as me.
Feedback here? People is too busy guessing game titles :wink:

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Mon Sep 29, 2008 1:09 pm

ppera wrote:
DrCoolZic wrote:I am waiting for eventual feedback on errors or better way to do things.


Better way? Assembler :mrgreen: Just kidding...
Better is for people who started with ASM, as me.
Feedback here? People is too busy guessing game titles :wink:

Yes I know I should probably invest some time in learning 68K ASM.
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!

User avatar
Desty
Atari God
Atari God
Posts: 1951
Joined: Thu Apr 01, 2004 2:36 pm
Location: 53 21N 6 18W
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby Desty » Mon Sep 29, 2008 1:55 pm

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.

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.
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!

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby DrCoolZic » Mon Sep 29, 2008 2:31 pm

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.

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 ? :wink:

User avatar
Desty
Atari God
Atari God
Posts: 1951
Joined: Thu Apr 01, 2004 2:36 pm
Location: 53 21N 6 18W
Contact:

Re: Writing simple GUI - yet another GEM demo coding in C

Postby Desty » Mon Sep 29, 2008 2:39 pm

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 ? :wink:

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.
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!


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 0 guests