and users not reading the the readme is a huge problem too. There are just some people where I just want to give them MOS ><
KermMartian wrote:
Sonlen wrote:
KermMartian wrote:
qazz42 wrote:
Ok, I will during HCWP Razz
Sounds like a plan. I will probably be doing laundry at least before HCWP, if not into part of HCWP, so I might not be able to make it until 9pm or worse.



D: I just can't believe that people can be that "slow" though I know it is true. :/
I know, it sucks. I'm having trouble thinking down to that level of user intelligence, I guess, since I took arrows moving the cursor for granted.


How would you take that for granted? That is how you navigate in the OS itself, and the other shells iirc.

Idea, make a screen that shows up before the "help" screen that requires a password you can only get in the user manual, and then have it a 1 time only thing so that they can send it to others.

Very Happy
Sonlen, bad idea actually, that scares them away from using it cause they think "Oh man, more work? I just want to get a shell, screw this"
I agree with qazz. (Did those words just come from my mouth?) While yes, I also agree that if it worked, it would get less nooby questions, it would still be a hassle for people to do just to get to the shell they wanted to hear about and test. One idea I just had on how to accomplish it, btw, is to steal maybe 20 bytes in DCS and see if you can't get it to store the calc id for the current calc there and when someone gives DCS away, it would check and see that it doesn't match the id of their calc, and give them a RTFM password input. Not the best idea (doesn't work after one person) and if you gave it to someone at school, they wouldn't be able to use it until either they went home, their friend remembers the password, or they just delete the app.
Kermm, I haven't tried Doors CS7.1 Beta, I use Doors CS7 normal, and when I hover a certain document, press Alpha for options for that document, the first one is delete and the second one is lock.

Well, I was trying to unlock a document, and mistakenly deleted because these two options are close from each other.

SO, my suggestion is a 'Are you sure you want to delete' dialog box, because this can happen, and now I'm really mad because I lost a lot of work.

It's an idea, I hope all like it because I love Wink
Yeah, I actually agree a little there should be a prompt. But I dont use the right click menu so much so I really am indifferent
qazz42 wrote:
Yeah, I actually agree a little there should be a prompt. But I dont use the right click menu so much so I really am indifferent


Yes, I found about it today and already got sad today.

Everything I had done on Formulum *sniff* *sniff* gone...
ScoutDavid wrote:
qazz42 wrote:
Yeah, I actually agree a little there should be a prompt. But I dont use the right click menu so much so I really am indifferent


Yes, I found about it today and already got sad today.

Everything I had done on Formulum *sniff* *sniff* gone...
I'm very sorry to hear it. Sad I don't have that because at one point it was indeed on the table, but people either found it an annoyance or just got so used to automatically confirming that it was useless. I'd be happy to reconsider.
Well, you got to admit, that was in the past, now we have new people who need the extra stuff because they are used to having it some other way (no offense intended)
hm...

What about a poll? That would be cool!
ScoutDavid wrote:
hm...

What about a poll? That would be cool!
Sure! You're welcome to start the topic and drop a poll into it if you want. Smile
*bump*

So, Doors CS 7.1 Beta 1 users, please remind me what issues are still pending. Since the CALCnet 2.2 project page is now nearly complete, including my video of Flourish in action (protip: nine-calculator networking goodness), I need to get Doors CS 7.1 out the door (hehe) ASAP. Right now I know about:

:: Awkward TI-OS + WFRNG problems
:: 2.53MP-triggered editor issue, believe to be DCS-independent
:: ZTrumpet's sum(L,S,T) issue

Did I miss anything? I have a few other things on my Bugs list but nothing that hasn't been there for several months without being bumped.
Cross Post by Request of Dr.Martian:

This might seem like user error, but I know for a fact it isn't.
When you have a RAM clear, and then you start drawing lines, and clearing the screen using real(0,1) it messes with the lines positions on the X axis, it shifts it about 5 or 6 pixels from the left if you have the X coordinate on the Xmin mark, but it seems using a clearDraw command completely fixes this issue.
If you want Kerm, I can help debug this if you can't seem to replicate it.

Steps:
1. Clear Ram
2. Use real(0,1), no clrDraw yet.
3. Draw a line with one of the X coordinates on 0, the other I don't think matters(also Kerm, you can try the code you posted for the EXP bar, as that is how I found out about this)
4. It should be off, now use a clrDraw before the line is drawn, and it should be fine
Sonlen wrote:
Cross Post by Request of Dr.Martian:

This might seem like user error, but I know for a fact it isn't.
When you have a RAM clear, and then you start drawing lines, and clearing the screen using real(0,1) it messes with the lines positions on the X axis, it shifts it about 5 or 6 pixels from the left if you have the X coordinate on the Xmin mark, but it seems using a clearDraw command completely fixes this issue.
If you want Kerm, I can help debug this if you can't seem to replicate it.

Steps:
1. Clear Ram
2. Use real(0,1), no clrDraw yet.
3. Draw a line with one of the X coordinates on 0, the other I don't think matters(also Kerm, you can try the code you posted for the EXP bar, as that is how I found out about this)
4. It should be off, now use a clrDraw before the line is drawn, and it should be fine
Bug sort of replicated using the following code:


Code:
0->Xmin:0->Ymin
1->deltaX:1->deltaY
real(0,1
Line(1,10,46,10
Pause


When run the first time after a RAM clear, it draws the line at the top of the screen, as if the window extents are still (-10,10,-10,10), the default ZStandard coordinates. Run it again, and it behaves. Further investigation reveals the following:

(1) The Xmin and Ymin are set
(2) The Xmax and Ymax are not set by deltaX/deltaY until a ClrDraw occurs.

The solutions to this "bug":
(1) Either call a ClrDraw after doing Xmin/Ymin/deltaX/deltaY OR
(2) Set Xmin/Xmax/Ymin/Ymax instead of using the deltaX/Y shortcut

Makes sense? Smile
KermMartian wrote:
Sonlen wrote:
Cross Post by Request of Dr.Martian:

This might seem like user error, but I know for a fact it isn't.
When you have a RAM clear, and then you start drawing lines, and clearing the screen using real(0,1) it messes with the lines positions on the X axis, it shifts it about 5 or 6 pixels from the left if you have the X coordinate on the Xmin mark, but it seems using a clearDraw command completely fixes this issue.
If you want Kerm, I can help debug this if you can't seem to replicate it.

Steps:
1. Clear Ram
2. Use real(0,1), no clrDraw yet.
3. Draw a line with one of the X coordinates on 0, the other I don't think matters(also Kerm, you can try the code you posted for the EXP bar, as that is how I found out about this)
4. It should be off, now use a clrDraw before the line is drawn, and it should be fine
Bug sort of replicated using the following code:


Code:
0->Xmin:0->Ymin
1->deltaX:1->deltaY
real(0,1
Line(1,10,46,10
Pause


When run the first time after a RAM clear, it draws the line at the top of the screen, as if the window extents are still (-10,10,-10,10), the default ZStandard coordinates. Run it again, and it behaves. Further investigation reveals the following:

(1) The Xmin and Ymin are set
(2) The Xmax and Ymax are not set by deltaX/deltaY until a ClrDraw occurs.

The solutions to this "bug":
(1) Either call a ClrDraw after doing Xmin/Ymin/deltaX/deltaY OR
(2) Set Xmin/Xmax/Ymin/Ymax instead of using the deltaX/Y shortcut

Makes sense? Smile


Forgot to mention I do set Xmin Xmax Ymin and Ymax in the FFME start program, which I always run after each ram clear so I have everything set how it usually is.
When I set Xmin/Xmax/Ymin/Ymax in that same code I presented above, my test program works properly even immediately after a RAM clear, as per my instructions. If your program still has problems, I would double-check that you're not using the deltaX/deltaY shortcut.
Here's a bunch of glitches and other miscellaneous problems Very Happy
Some of them aren't really worth fixing, but reporting them is better than nothing, amirite?
I'm using 2.43.


1. Gotoing to a TI-BASIC error when using DCS will goto the correct line, but it does not jump to the correct position within the line. This turned out to be troublesome for me when I tried to run a program that was 400 bytes of DelVar instructions on a single line...

2. A while ago, I tried making an asm program on-calc. It looked like this:

Code:
:AsmPrgm
:C9
(hurr durr most useful code ever)
It didn't work in DCS without using AsmComp(, as stated by others earlier. However, the AsmComp('d version was a bit glitchy in the icon and description. The icon was competely white when in RAM and completely black when in archive. The description was random garbage text, and it changed when doing stuff such as closing DCS and archiving the program.

3. When using the various keyboard shortcuts instead of the mouse, InfoPop may appear because the mouse was pointing at something, which can be annoying. This mainly happens when DCS has just started and no keys have been pressed yet. Would it be possible to not show InfoPop unless the cursor has actually moved?

4. Empty programs show up as having a size of 0 bytes. Is this intentional? Obviously the VAT entry must larger than 0 bytes.

5. Hiding a program and then editing it from DCS so that it starts with Ans or rand makes the program inaccessible from both DCS and TI-OS. The only way to get rid of it seems to be a RAM clear, or a full mem clear if the program was archived.

6. Hiding an archived program makes DCS get stuck sometimes (infinite hourglass). I think it has also happened once when archiving a hidden program. Archive does not become corrupted if a battery is pulled.

7. The first character of descriptions of hidden programs usually changes to 5, 8, :, ;, (, ), ,, <, ? or a similar character. The character seems to be completely random, but it does not change over time. Programs that use descriptions other than just the program name do not seem to be affected.
JosJuice wrote:
Here's a bunch of glitches and other miscellaneous problems Very Happy
Some of them aren't really worth fixing, but reporting them is better than nothing, amirite?
I'm using 2.43.

1. Gotoing to a TI-BASIC error when using DCS will goto the correct line, but it does not jump to the correct position within the line. This turned out to be troublesome for me when I tried to run a program that was 400 bytes of DelVar instructions on a single line...
Yup, this was a design decision meant to make the display method a little cleaner. I'll stick with what I have for now, but I'll remember this in case other people complain. Smile

Quote:
2. A while ago, I tried making an asm program on-calc. It looked like this:

Code:
:AsmPrgm
:C9
(hurr durr most useful code ever)
It didn't work in DCS without using AsmComp(, as stated by others earlier. However, the AsmComp('d version was a bit glitchy in the icon and description. The icon was competely white when in RAM and completely black when in archive. The description was random garbage text, and it changed when doing stuff such as closing DCS and archiving the program.
There's an excellent reason for this. C9 (ret) is the first byte of Ion and DCS programs, to prevent the TI-OS from running them. Doors CS assumes that a program with ret as the first byte is one of those two type, and doesn't bother doing a length check for the sake of its sanity. However, since the data after the C9 depends on whatever is next in memory, that will change as programs are sorted and reordered. Hence the behavior you were seeing, which I don't really consider a bug. Smile When it doubt, prepend significant headers like that with a nop ($00).

Quote:
3. When using the various keyboard shortcuts instead of the mouse, InfoPop may appear because the mouse was pointing at something, which can be annoying. This mainly happens when DCS has just started and no keys have been pressed yet. Would it be possible to not show InfoPop unless the cursor has actually moved?
I suppose I could do a cheap "if (x!=45 and y!=32) and if cursor has hovered for X seconds then InfoPop()"... What do other people think about that?

Quote:
4. Empty programs show up as having a size of 0 bytes. Is this intentional? Obviously the VAT entry must larger than 0 bytes.
For ASM coders, if not other coders, I think that the pure data size of the program is the important part, not the 2-byte size word or the seven-and-up byte VAT entry. Smile Therefore, InfoPop only displays the size of the program data itself. Does this disparity with what the TI-OS chooses to do bother you?

Quote:
5. Hiding a program and then editing it from DCS so that it starts with Ans or rand makes the program inaccessible from both DCS and TI-OS. The only way to get rid of it seems to be a RAM clear, or a full mem clear if the program was archived.
This is correct. Not too much to be done about that other than popping open CalcSys and renaming the program, which would save you a RAM Clear.

Quote:
6. Hiding an archived program makes DCS get stuck sometimes (infinite hourglass). I think it has also happened once when archiving a hidden program. Archive does not become corrupted if a battery is pulled.
Now this one is interesting. I've never happen to run across this before; is it replicable? In other words, is there a pattern to when it happens?

Quote:
7. The first character of descriptions of hidden programs usually changes to 5, 8, :, ;, (, ), ,, <, ? or a similar character. The character seems to be completely random, but it does not change over time. Programs that use descriptions other than just the program name do not seem to be affected.
An excellent point, and something that should be fairly easy to work around. Actually, there is a pattern. If you look closely, you'll see that every hidden program that has a name that starts with the same letter has the same random character in the description; this is a side effect (or actually the main effect) of how programs are actually hidden from the TI-OS.

Thanks for the thorough report!
KermMartian wrote:
Quote:
4. Empty programs show up as having a size of 0 bytes. Is this intentional? Obviously the VAT entry must larger than 0 bytes.
For ASM coders, if not other coders, I think that the pure data size of the program is the important part, not the 2-byte size word or the seven-and-up byte VAT entry. Smile Therefore, InfoPop only displays the size of the program data itself. Does this disparity with what the TI-OS chooses to do bother you?
It's not really a problem. In fact, what the TI-OS displays can be a bit confusing even to non-programmers, since archived files also take up space in RAM.
KermMartian wrote:
Quote:
6. Hiding an archived program makes DCS get stuck sometimes (infinite hourglass). I think it has also happened once when archiving a hidden program. Archive does not become corrupted if a battery is pulled.
Now this one is interesting. I've never happen to run across this before; is it replicable? In other words, is there a pattern to when it happens?
There doesn't seem to be a pattern to it, but it has happened a few times. The times it did happen was when I first deleted a program (hidden, archived) and sent a new program to the calc (archived), but I don't know if that has anything to do with it.
KermMartian wrote:
Quote:
7. The first character of descriptions of hidden programs usually changes to 5, 8, :, ;, (, ), ,, <, ? or a similar character. The character seems to be completely random, but it does not change over time. Programs that use descriptions other than just the program name do not seem to be affected.
An excellent point, and something that should be fairly easy to work around. Actually, there is a pattern. If you look closely, you'll see that every hidden program that has a name that starts with the same letter has the same random character in the description; this is a side effect (or actually the main effect) of how programs are actually hidden from the TI-OS.
That's an interesting method of hiding programs! Do other shells work in this way as well?
JosJuice wrote:
KermMartian wrote:
JosJuice wrote:
4. Empty programs show up as having a size of 0 bytes. Is this intentional? Obviously the VAT entry must larger than 0 bytes.
For ASM coders, if not other coders, I think that the pure data size of the program is the important part, not the 2-byte size word or the seven-and-up byte VAT entry. Smile Therefore, InfoPop only displays the size of the program data itself. Does this disparity with what the TI-OS chooses to do bother you?
It's not really a problem. In fact, what the TI-OS displays can be a bit confusing even to non-programmers, since archived files also take up space in RAM.
That's my thought as well, as you can see from my design choice, so I think I'll leave it that way for now.

JosJuice wrote:
KermMartian wrote:
JosJuice wrote:
6. Hiding an archived program makes DCS get stuck sometimes (infinite hourglass). I think it has also happened once when archiving a hidden program. Archive does not become corrupted if a battery is pulled.
Now this one is interesting. I've never happen to run across this before; is it replicable? In other words, is there a pattern to when it happens?
There doesn't seem to be a pattern to it, but it has happened a few times. The times it did happen was when I first deleted a program (hidden, archived) and sent a new program to the calc (archived), but I don't know if that has anything to do with it.
Have you done a full Mem Clear in between any of the instances? Is it possible you might have some corruption in your archive, or is that unlikely? I doubt that's the case; I'm just trying to think what could cause these symptoms.

JosJuice wrote:
KermMartian wrote:
JosJuice wrote:
7. The first character of descriptions of hidden programs usually changes to 5, 8, :, ;, (, ), ,, <, ? or a similar character. The character seems to be completely random, but it does not change over time. Programs that use descriptions other than just the program name do not seem to be affected.
An excellent point, and something that should be fairly easy to work around. Actually, there is a pattern. If you look closely, you'll see that every hidden program that has a name that starts with the same letter has the same random character in the description; this is a side effect (or actually the main effect) of how programs are actually hidden from the TI-OS.
That's an interesting method of hiding programs! Do other shells work in this way as well?
Yes indeed; every shell that hides programs from the TI-OS, as far as I know, does so by modifying the first letter of the name to be outside the TI-OS' range of what it considers valid first letters.
  
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
» Goto page Previous  1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Page 5 of 6
» 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