Raylin wrote:
The myButton2 which basically opens a smallWin and has text inside doesn't appear at all. The rest of the program calls GUIMouse and works fine.
The problem isn't jumping out at me, so I'll run your program and edit this post in a moment.

Edit: Your y-coordinate for myButton2 is too large. Smile The coordinates are relative to the top-left of the GUIRLargeWin's blank area, not the top-left of the LCD; try 45 or 46 or so.
It works! Very Happy
Raylin wrote:
It works! Very Happy
Awesome; I love your title screen thus far, btw.
Thank you sir.
Raylin wrote:
Thank you sir.
Of course. Smile I don't think you should try this yet, but you can save some space by using PushGUIStacks instead of PushGUIStack, and because of all the blank space in your main logo, you should use a GUIRNull plus a GUIRLargeSprite to save all that empty space of %00000000s.
How do you save things to appvars?
Raylin wrote:
How do you save things to appvars?
Actually, since this is an ASM program instead of an app, you can save things directly into the program. Doors CS 7's Intelligent Writeback feature will prevent extraneous archive writes in case nothing has changed.
KermMartian wrote:
Raylin wrote:
How do you save things to appvars?
Actually, since this is an ASM program instead of an app, you can save things directly into the program. Doors CS 7's Intelligent Writeback feature will prevent extraneous archive writes in case nothing has changed.


Intriguing. How does the Intelligent Writeback feature work? Could I get an example?
Raylin wrote:
KermMartian wrote:
Raylin wrote:
How do you save things to appvars?
Actually, since this is an ASM program instead of an app, you can save things directly into the program. Doors CS 7's Intelligent Writeback feature will prevent extraneous archive writes in case nothing has changed.


Intriguing. How does the Intelligent Writeback feature work? Could I get an example?
Sure thing. Basically, you can have both code and data in an assembly program. If your program is stored in RAM while it's not running, then you're free to modify anything in the program without consequence. If your program is stored in Archive, you can still modify anything in the program, but before the program is run, it needs to be unarchived, and after it's been run, it needs to be re-archived. Of course, that incurs a wear cycle on the Flash every time you run the program.

Doors CS does something a bit more intelligent. Instead of unarchiving programs, it copies them from archive to RAM into a temporary program. After the program finishes executing, Doors CS compares the temporary RAM copy to the archived copy. If they're the same, it simply discards the RAM copy. If they're different, it deletes the archived copy and renames and archives the RAM copy.
Okay then. Cool. So, if I wanted to save, say, a set of values... I would just leave them in the registers?
Raylin wrote:
Okay then. Cool. So, if I wanted to save, say, a set of values... I would just leave them in the registers?


Not quite. Say at the bottom of your program you had this:

Code:
MySavedData:
.db 0,0,0
Then, in order to save 1,2,3 into the program, you could do the following:

Code:
   ld hl,MySavedData
    ld (hl),1
    inc hl
    ld (hl),2
    inc hl
    ld (hl),3
You could of course also do something like this:

Code:
    ld a,1
    ld (MySavedData),a


When you run the program the next time, you can do this:

Code:
    ld a,(MySavedData)
and the a register will contain 1. If you instead did this:
Code:
    ld a,(MySavedData+1)
then a would contain 2.

Makes sense?
Okay. Also, my program's freezing again. Why is this?

I change b to 4 and it works but, it deletes my Settings buttons. I set it to 3 and it freezes.
I set it to 2; it crashes.

Source code
Raylin wrote:
Okay. Also, my program's freezing again. Why is this?

I change b to 4 and it works but, it deletes my Settings buttons. I set it to 3 and it freezes.
I set it to 2; it crashes.

Source code
ld b,3 is fine, but I happen to notice that you're failing to load 0 to hl before calling GUIMouse there... Razz
Cool.
Cool.
Working on GUIRTextLineIn now.
Can you get rid of the garbage in the box on initialization?
Raylin wrote:
Cool.
Cool.
Working on GUIRTextLineIn now.
Can you get rid of the garbage in the box on initialization?
Their shouldn't be any garbage. Make sure that even if you want a blank string in it at the beginning that you specify .db 0 as the string (just a null terminator), not [nothing].

Code:

myText:
   .db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
myTextBox:
   .db 1,8,40
   .dw 16
   .dw 0
   .dw myText
   .db 0


Still doesn't work. It displays "/i". The i has an accent on it.
Whoa, what the hell are you doing there? The text field needs to be the actual text, not a pointer to a save string. Very Happy

myTextBox:
.db 1,8,40
.dw 16
.dw 0
.db 0
Okay.
And, to get said value, you GUIFindFirst and store those values into the save pointer?
Raylin wrote:
Okay.
And, to get said value, you GUIFindFirst and store those values into the save pointer?
Well, if you have GUIRSmallWin / GUIRTextInput, you GUIFindFirst. If you have GUIRSmallWin / GUIRWinButtons / GUIRTextInput, you'll need GUIFindFirst, then GUIFindNext. See the pattern? Smile
Yeah. It's going through the stack. Cool. Cool.
  
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
Page 3 of 5
» 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