yes. Counting them real quick... 71 programs.
_player1537 wrote:
yes. Counting them real quick... 71 programs.
So eleven full screens and then five on the last screen? And if you hover over the final empty space, you get an incorrect InfoPop (or indeed an InfoPop at all, since you should get non). 
correct. And it shows the data from the page up one from the last that would be in that spot. Ie I think my last 6 programs are: ZZZZZ,ZZZZZ0,ZZZZZ1,ZZZZZ2,ZZZZZ3,ZZZZZ4,ZZZZZ5. When I hover over that last spot, it gives me data for ZZZZZ.
_player1537 wrote:
correct. And it shows the data from the page up one from the last that would be in that spot. Ie I think my last 6 programs are: ZZZZZ,ZZZZZ0,ZZZZZ1,ZZZZZ2,ZZZZZ3,ZZZZZ4,ZZZZZ5. When I hover over that last spot, it gives me data for ZZZZZ.
Would it be at all possible for you to group one of your files to save it, then delete it so you have two spots free, and see if both spots display this bug? 
cool...
i found no bugs or problems so far...
and i find the new features awesome!
the smaller menu is nicer, and the memorization of where you were when you last used it is sweet!
i found no bugs or problems so far...
and i find the new features awesome!
the smaller menu is nicer, and the memorization of where you were when you last used it is sweet!
oh, the same thing happens no matter what/how many programs are on the last page. I tried it earlier before the original post
WhiteValkery wrote:
cool...
i found no bugs or problems so far...
and i find the new features awesome!
the smaller menu is nicer, and the memorization of where you were when you last used it is sweet!
Thanks WhiteValkery! I'm overjoyed to hear that you're not running into any bugs.
i found no bugs or problems so far...
and i find the new features awesome!
the smaller menu is nicer, and the memorization of where you were when you last used it is sweet!
@_player: So it still happens in _every_ blank spot, not just the one immediately following the last one? This one is gonna be a pain to track down. >_<
Haha, these GUImenus are much better than the ti-os menu's
It seems that they are cooler and nicer to interface with
It seems that they are cooler and nicer to interface with
qazz42 wrote:
Haha, these GUImenus are much better than the ti-os menu's
It seems that they are cooler and nicer to interface with
Hehe, very happy to hear it! I hope you're able to make good use of them. It seems that they are cooler and nicer to interface with
Yep, no more need for custom menus! Now I can use yours, problem is that, I cant make too many prgms that require DCS, perhaps you can make a separate prgm or app that just activates them?
qazz42 wrote:
Yep, no more need for custom menus! Now I can use yours, problem is that, I cant make too many prgms that require DCS, perhaps you can make a separate prgm or app that just activates them?
Not a chance. Even just pulling out that one part of the GUI system would probably require a good 8KB, although I'm sure I could fake it in 1-2KB.
*bump*
For those who want to check out the multiple AnsStacks:
http://www.cemetech.net/files/dcs6.8.5_beta.8xk
For those who want to check out the multiple AnsStacks:
http://www.cemetech.net/files/dcs6.8.5_beta.8xk
okay, big bug with GUImenu, I made a GUImenu that pretty much says
1. Send
2. Recieve
Now, send stores text into a string while Recieve gets the string from the calc that stored it (with getcalc())
Now, getcalc does nothing if you click receive from the GUmenu, but from a TI-OS menu, everything will be fine.
1. Send
2. Recieve
Now, send stores text into a string while Recieve gets the string from the calc that stored it (with getcalc())
Now, getcalc does nothing if you click receive from the GUmenu, but from a TI-OS menu, everything will be fine.
qazz42 wrote:
okay, big bug with GUImenu, I made a GUImenu that pretty much says
1. Send
2. Recieve
Now, send stores text into a string while Recieve gets the string from the calc that stored it (with getcalc())
Now, getcalc does nothing if you click receive from the GUmenu, but from a TI-OS menu, everything will be fine.
[The word is Receive: i before e except after c, with a few exceptions like neighbor and weigh].
1. Send
2. Recieve
Now, send stores text into a string while Recieve gets the string from the calc that stored it (with getcalc())
Now, getcalc does nothing if you click receive from the GUmenu, but from a TI-OS menu, everything will be fine.
Very interesting; can you send me the program that displays this behavior? I would like to try it. This makes two bugs I need to solve, Player's InfoPop bug and your GetCalc bug.
qazz42 wrote:
Umm, sure, I better make a prgm that just getcalc then..
Just run your program through SourceCoder and pick out the sum(13) and the two labels it jumps to. 
Edit: Wait, are you saying that you can't GetCalc from one calculator while the other calculator is at the GUIMenu or while it's sitting in a Pause or an Input? qazz42 wrote:
While it is at a GUImenu, it works fine at a TI-OSmenu...
Well yeah, because a TI-OS menu uses GetKey, and a GUIMenu uses something more complex and non-interruptable. No big surprises there. Register to Join the Conversation
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
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