ACagliano wrote:
Kool. Suddenly the cryptic becomes less cryptic. Thanks.
That's excellent; very happy to hear it. Smile You're most welcome. I see that HTML uses the name="" field for the same thing, but I had chosen to use something a little less (to me) confusing.
Ok, here's what I'm on about...

I want to be able to have a string that contains a username. Such that the string can be displayed with a GUIR routine and that I can edit with the GUIRTextLineIn.

Edit: Forgot to ask...you were discussing making more than one hub in the other post. How would you make a hub?
ACagliano wrote:
Ok, here's what I'm on about...

I want to be able to have a string that contains a username. Such that the string can be displayed with a GUIR routine and that I can edit with the GUIRTextLineIn.


Blah

Regarding virtual hubs and metahubs. The "metahub" is the whole gCn hub process running on one of my servers that moderates all current gCn traffic. There's currently only one of these, but in the future, if it gets overloaded, there could be other ones added. Anyway, the metahub contains lots of virtual hubs, named things like "IRCHub" and "WebHub" etc, but, and I cannot stress this enough, connecting to a hub with any name creates a hub with that name. When all the users of a particular hub leave, it disappears. So there's no need to expressly reserve or create hubs.
Ok. I understand. What about my GUI issue? How would I do that?
ACagliano wrote:
Ok. I understand. What about my GUI issue? How would I do that?
Haha, I was supposed to fill in the answer to that in the "Blah" part before I posted the post, but clearly I completely forgot to do so. Smile Anyway.

All you need to do is construct the text input element(s) in some scratch memory area, then push them onto the stack. By constructing them in scratch RAM, you can just copy the string you want the element to be initialized with into it, then push it, without having to worry about manipulating the stack live or something. And of course, once you regain control, you can use GUIFindFirst, GUIFindThis, and GUIFindNext to get the strings out again.
Ah, I think I understand. Now, let me ask you.

GUIFindFirst locates the first non-groupmaster element.
GUIFindThis and ...FindNext seem to both just find the next element.
But, if "FindFirst" starts at the first non-gm, then the others move down the stack, how do you just up to the next gm?
ACagliano wrote:
Ah, I think I understand. Now, let me ask you.

GUIFindFirst locates the first non-groupmaster element.
GUIFindThis and ...FindNext seem to both just find the next element.
But, if "FindFirst" starts at the first non-gm, then the others move down the stack, how do you just up to the next gm?
Basically, you want to either use GUIFindFirst + GUIFindNext to wander through the stack, or just use GUIFindThis to go exactly to where you want to be. The first two are if you need to look at a few different elements on the stack, and save clock cycles for advancing to other items. The latter is better if you have a single item on the stack in which you're interested.
Well, I would only be interested in one element, the one I'm pushing. How would I use GUIFindThis to find it?
ACagliano wrote:
Well, I would only be interested in one element, the one I'm pushing. How would I use GUIFindThis to find it?
Say you push a GUIRSmallWindow, then a GUIRWinButtons, then a GUIRText, then a GUIRTextInput. Since the groupmaster (the small window) isn't accessible or anything, you'd GUIFindThis to 0 for the WinButtons, to 1 for the Text, and to 2 for the TextInput.
KermMartian wrote:
ACagliano wrote:
Well, I would only be interested in one element, the one I'm pushing. How would I use GUIFindThis to find it?
Say you push a GUIRSmallWindow, then a GUIRWinButtons, then a GUIRText, then a GUIRTextInput. Since the groupmaster (the small window) isn't accessible or anything, you'd GUIFindThis to 0 for the WinButtons, to 1 for the Text, and to 2 for the TextInput.


Ok, that I get. Now one final question. When, in the SingleLineTextIn, you say "current offset to start of data string", what does that mean? Edit: And is "zero terminated string" what to display above the input box, or the initial string in the box? That confuses me a bit. Could we mod the DCS wiki to be a bit more specific about that?
That's relevant to the side-to-side scrolling. When you scroll far to the right, the first character visible is not the first character of the string, but a character later in the string. That number is the offset of that character. Smile
KermMartian wrote:
That's relevant to the side-to-side scrolling. When you scroll far to the right, the first character visible is not the first character of the string, but a character later in the string. That number is the offset of that character. Smile


Oh, so I can just make that .dw 0? And what about the text sting. I edited the above post with that.
ACagliano wrote:
KermMartian wrote:
That's relevant to the side-to-side scrolling. When you scroll far to the right, the first character visible is not the first character of the string, but a character later in the string. That number is the offset of that character. Smile


Oh, so I can just make that .dw 0? And what about the text sting. I edited the above post with that.
It's the string inside the box. If you want a string above the box, you use a GUIRText item.
Ah. Would you mind editing the DCS wiki at ur convenience, to make that specification?
ACagliano wrote:
Ah. Would you mind editing the DCS wiki at ur convenience, to make that specification?
I'm a bit busy; do you have an account there so you can make the clarifications? Smile

Code:
;#####################
;Change Username
;#####################
;
;Allows you to change your username:
;

Username:
    ld  b,4
    call    PopGUIStacks
    ld  hl,ChangeUsernameData
    ld  de,saferam2
    ld  bc,ChangeUsernameDataEnd+1-ChangeUsernameData
    ldir
    ld  hl,saferam2
    call    PushGUIStacks

ProcessUsername:
;have to write this yet.


ChangeUsernameData:
    .db 4
    .dw UsernamePrompt-ChangeUsernameData
    .db 1,1,0
    .db 0,0,0,0,0,0,0,0,0
UsernamePrompt:
    .db 9
    .dw UsernameSubmitButton-UsernamePrompt
    .db 2,10,50
    .dw 8
    .dw 0
    .db 0,0,0,0,0,0,0,0,0
UsernameSubmitButton:
    .db 7
    .dw ChangeUsernameDataEnd-UsernameSubmitButton
    .db 30,25
    .dw ProcessUsername
    .db "Submit",0
ChangeUsernameDataEnd:
    .db $FF,$FF


Currently, this code should push the items from RAM into the stack. After use, the items are popped. Am I on the right track with this? Or did you mean something else?

Edit: Now I can just ldir the data from the Username/password locations into these elements and then back into their locations from the stack, right?
Bump^^.
That's exactly correct! Let me help you out with an example that I use in Sandpaper:


Code:
[...]
StartAskUsername:
   CloseGUIStack()
   OpenGUIStack()
   ld hl,UsernameWinData
   call PushGUIStacks
   GUIFindThis(1)
   ld de,10
   add   hl,de
   ld de,MyUsername
   ld bc,8
   ex de,hl
   ldir
   GUIMouse(0)
StartAskUsernameProcess:
   call ResetAppPage
   GUIFindThis(1)
   ld de,10
   add   hl,de
   ld a,(hl)
   or a
   jp z,StartAskUsername
   ld de,MyUsername
   ld bc,8
   ldir


Notice the copying from MyUsername into the GUI, and the later copying of MyUsername out of the GUI. The GUI itself is this:


Code:
;--------------------------------------------------------------------------------
; Username input window stuff
;--------------------------------------------------------------------------------
UsernameWinData:
   .dw UsernameWinDataE-UsernameWinData
   .db GUIRSmallWin
   .db 5,5
   .db %01100000
   .db %10010000
   .db %11110000
   .db %10010000
   .db %11110000
   .db "User/Calc Name",0
UsernameWinDataE:

UsernameWinButtons:
   .dw UsernameWinButtonsE-UsernameWinButtons
   .db GUIRWinButtons
   .db %00100000
   .dw 0, 0
   .dw StartAskUsernameProcess
UsernameWinButtonsE:

UsernameIn:
   .dw UsernameInE-UsernameIn
   .db GUIRTextLineIn
   .db 19,1
   .db 50
   .dw 8
   .dw 0
   .db 0,0,0,0,0,0,0,0,0
UsernameInE:
UsernameTextPrompt1:
   .dw UsernameTextPrompt1E-UsernameTextPrompt1
   .db GUIRText
   .db 1,1,0
   .db "User:",0
UsernameTextPrompt1E:
UsernameTextPrompt2:
   .dw UsernameTextPrompt2E-UsernameTextPrompt2
   .db GUIRWrappedText
   .db 1,9,78,0
   .db "Other calcs will see you",$D6
   .db "with this name",0
UsernameTextPrompt2E:
UsernameSetButton:
   .dw UsernameSetButtonE-UsernameSetButton
   .db GUIRButtonText
   .db 55,31
   .dw StartAskUsernameProcess
   .db "Apply",0
UsernameSetButtonE:
   .db $ff,$ff
Oh, I remember. I don't think it's a travesty if this doesn't get done, but it would be kool. I want to do this on both the username and password prompts. If the username and password are both null (9 bytes of 0's), then the cancel button is not shown. It is only shown if there is valid data there (this will force a username and password the first time). And I want to show the submit button only if the data has changed, but not if the data is the same or has been completely erased. Would this require


Code:

ld  hl,HookCode
call GUIMouse

??
You could probably do that, yeah, but the only problem is that mousehooks don't trigger while the user is typing into a text field, only when the mouse is active. It's something I've regretted again and again.
  
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 2 of 4
» 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