Axe GUI Library
» >
»
» View previous topic :: View next topic  
Some of you might know already, I created an Axe GUI Library. Since it is an Axe project, I made a topic at Omnimaga, you can find it here.

This project will be developed by me, Ashbad and whoever who wants to join.

However, we are considering a side-project since Kerm has proofed that using DCS GUI API together with Axioms would be a better option.

I was not convinced by his arguments, hence I plan on keeping an Axe-only library. However, we have considering having a mix or a side project, two libraries, one with Axioms and another with Axe code.

The reason why I'll keep the Axe one is because changing its code (of the GUI Library) would be easier for Axe programmers if that code was in Axe and not in Assembly, since not all Axe programmers know Assembly. In addition, the DCS GUI API would make it DoorsCS-only.

However, using the DCS GUI API would make programs faster, the library would be easier to code and DCS GUI is wonderful (IMO).

Let me know what you think. This is a discussion topic.
ScoutDavid, first, let me copy over some screenshots from the topic you linked:



In my opinion, it's basically a direct copy of the Doors CS GUI libraries, but for Axe, and since I spent many weeks and months of my life doing all the hard work in coding annoying things like mouse hotspot stuff, and super-optimized ASM tricks to access the GUI stack, and the headaches of variable-width text input, I was hoping that then other people would be able to benefit by using the libraries and not having to worry about that annoying low-level stuff. I definitely understand the argument that for people who want something custom, a modifiable library is better. However, I have two counter-arguments:

(1) The Doors CS libraries wrapped in an Axiom would work well for people who are happy with standard GUI libraries
(2) The Doors CS libraries have a fair amount of extensibility built-in, including the capability for things like mousehooks, custom cursors, custom hovers, and all that, so if things like that were brought out through the Axiom, I believe people would enjoy the extensibility.

Bottom line, I think that both might be useful to different people, but I think that there are definitely arguments in favor of both. As far as the DCS-only caveat, I don't really consider that too much of a downside. Wink Having Doors CS-only programs is one way to push Doors CS into the larger world, just as MOS having features making its games not work on Ion made people install MOS over Ion.
I'd like to announce we reached a good deal and I guess this is the best for everyone.

http://code.google.com/p/axe-gui-libraries/

Two Libraries
Same Team
Same Project
Same Name
Different Code

Me, Ashbad and alberthrocks are working on this. However, more are allowed to join and we hope so happens.
I will of course be providing the guidance for the ASM side of it from a Doors CS perspective and helping you guys to understand the marshalling and unmarshalling necessary. Smile
Thanks KermM Very Happy

http://code.google.com/p/axe-gui-libraries/issues/list

If you guys check the Issues page we already got our first problem Razz
Firstly, I would strongly recommend using the Doors CS SDK as your assembler, unless you're happy with SPASM for now. Other than that, the code looks fine for now; I'm not seeing the problem. Is the difficulty passing in the data from the arguments?
KermMartian wrote:
Firstly, I would strongly recommend using the Doors CS SDK as your assembler, unless you're happy with SPASM for now. Other than that, the code looks fine for now; I'm not seeing the problem. Is the difficulty passing in the data from the arguments?


I use the SDK, with the bat files and stuff. Not sure what alberthrocks uses though.

KermM: The problem is this for alberthrocks.
Some assembly experts? We have all the non-calc84 assembly experts, perhaps? Wink Yes, alberthro is welcome to post here, I see a few errors in his code. If he could post here what exactly the symptoms of the crash are, that would be helpful.
KermMartian wrote:
Some assembly experts? We have all the non-calc84 assembly experts, perhaps? Wink Yes, alberthro is welcome to post here, I see a few errors in his code. If he could post here what exactly the symptoms of the crash are, that would be helpful.


Albert can't be very active now due to Lent, but I'll ask him to give details of the crash.
Sounds good, I'd appreciate that. Also, Ashbad was saying some interesting things about the two parallel projects (Axiom & raw Axe) on Saturday, I'm not sure if you talked to him about it yet.
KermMartian wrote:
Sounds good, I'd appreciate that. Also, Ashbad was saying some interesting things about the two parallel projects (Axiom & raw Axe) on Saturday, I'm not sure if you talked to him about it yet.


I did talk about it, but we got to the conclusion that we really need a pure Axe GUI Library.
Ah, ok, I was hearing the opposite from him. Anyway, how are these going, the Axe and Axiom forms, respectively?
KermMartian wrote:
Ah, ok, I was hearing the opposite from him. Anyway, how are these going, the Axe and Axiom forms, respectively?


AFAIK, the axiom is stuck due to Assembly issues, Ashbad is working on the raw Axe version, so I'm waiting for him to upload source, which we should have done some time ago, to develop further.
The assembly issues that Alberthro apparently ran into? I wish someone would post here what the exact issue is so I can help solve it. Sad
Quote:

Sparking from this topic, I've decided to try and see if I can write a DCS axiom! Smile However, my assembly is terrible, so I will need LOTS of help with it. From the messages in the thread, it seems that our assembly devs are puzzled at how to write an Axiom, but could easy make an ASM program. Hopefully, from this topic, a quick start/manual can be written on how to write Axioms. THEN our awesome assembly programmers' powers can be unleashed! Wink

OK, so let's get started! Very Happy

First off, I'm basing my Axiom from the MemKit template. My assembler is SPASM (part of the WabbitStudio suite), OS Linux.
I also am using http://dcs.cemetech.net/index.php?title=GUI_API for reference on how to use the DCS' GUI libraries in assembly.
With that, I'm currently just trying to write example code for myself (and probably others).
I'm focusing on: http://dcs.cemetech.net/index.php?title=GUI_API#Adding_GUI_Elements

Here's a code snip from the API docs:

Code:
ld hl,SmWinData
ld de,SmWinDataEnd-SmWinData
ld a,GUIRSmallWin
call PushGUIStack
ld hl,winButtons
ld de,dat_end-winButtons
ld a,GUIRWinButtons
call pushGUIStack
ld hl,0
call GUIMouse
ret
SmWinData:
     .db 5,5     ;the x and y coordinates relative to the LCD of the top-left of the window
     .db $F8,$88,$88,$88,$F8   ;a square icon
     .db "My Window",0    ;the window title
SmWinDataEnd:
exitMyProg:
  call ResetAppPage
  ret
winButtons:
 .db 00100000b      ;only displaying a close button
 .dw 0              ;null pointer
 .dw 0              ;another null pointer
 .dw exitMyProg     ;we'll jump to exitMyProg when this button is clicked
dat_end:


Of course, we really don't want internal data, but the data for the arguments the user provides! Smile

In the end, after a back and forth on IRC, I've gotten this code:

Code:
.nolist
#include "ti83plus.inc"
#include "Axe.inc"
#include "dcs7.inc"
.list

#define B_CALL(xxxx) rst 28h \ .dw xxxx

 .dw AXM_HEADER

 .dw Ax1_End
 .db AXM_ALL
 .dw tok_DrawL   ;DlgBox()
 .db AXM_INLINE
 .db AXM_1ARG
 .org 0
 ; OLD CODE:
 ; call OpenGUIStack
 ; ld hl,SmWinData
 ; ld de,SmWinDataEnd-SmWinData
 ; ld a,GUIRSmallWin
 
 ; OK, so let's first get stuff ready! (Open the GUI stack!)
 call OpenGUIStack
 ; Text is stored in HL already, no need to move it around!
 ; Save hl!
 push hl
 ; Now find the length of the string arg!
 call sub_Length
 ; Copy it to the correct place...
 ex de,hl
 ; ...and bring back the string arg!
 pop hl
 ; Set window type!
 ld a,GUIRSmallWin
 
 ; Push the GUI!
 call PushGUIStack
 
 ; Now, add the close button to the window.
 ld hl,winButtons
 ld de,dat_end-winButtons
 ld a,GUIRWinButtons
 call pushGUIStack

 ; Now, render the GUI and give control (mouse) to DCS!
 ld hl,0
 call GUIMouse

 ret

exitMyProg:
  call ResetAppPage
  ret
winButtons:
 .db 00100000b      ;only displaying a close button
 .dw 0              ;null pointer
 .dw 0              ;another null pointer
 .dw exitMyProg     ;we'll jump to exitMyProg when this button is clicked
dat_end:
Ax1_End:

 .dw AXM_END

.end


Unfortunately, this crashes! Sad Is there any errors that should be fixed?
For this code:


Code:
 ; OK, so let's first get stuff ready! (Open the GUI stack!)
 call OpenGUIStack
 ; Text is stored in HL already, no need to move it around!
 ; Save hl!
 push hl
 ; Now find the length of the string arg!
 call sub_Length
 ; Copy it to the correct place...
 ex de,hl
 ; ...and bring back the string arg!
 pop hl
 ; Set window type!
 ld a,GUIRSmallWin
 
 ; Push the GUI!
OpenGUIStack most certainly trashes whatever he thinks he has saved in hl. What's that piece of code supposed to do, exactly?
call OpenGUIStack sets hl to null or a random unusable value?

Thanks.
No, but if you read this page, you'll see it returns the first byte of the GUIStack in hl (which isn't really useful to you in this case):

http://dcs.cemetech.net/index.php?title=OpenGUIStack
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Axe GUI Library
»
» View previous topic :: View next topic  
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement