Out of curiosity, isnt that the same Tiwizard site I told you about?

Erm, I think you're misunderstanding what sum(13) is supposed to do. 🙂 I've been hearing from people that they want some kind of Menu( alternative, but with the GUI, so I've been working on something like:

Code:
This will make a GUIRSmallWin with the specified title and icon, list the items, be scrollable (but use simple key stuff, not the mouse), and Goto a label when an option is chosen.

ComicIDIOT's ideas could be sum(14

They could, but that would be hugely complex for me to implement. It would be much much easier for a BASIC programmer to just fake the DCS desktop with GUI elements, which wouldn't actually take more than a rectangle, some sprites, and a scrollbar.

No Kerm 😁 , its the F double S OTD Funky Screwup Screenshot Of The Day at my website www.sourcecore.webs.com.

I lost my last beta and was to lazy to download a new one.Of course, I forgot only the new beta had PushGUIStacks and GUIFindThis and tried it on DoorsCS6.2 It is kinda strange how it only affects the right panel of the screen, isn't it?If you have an FSSOTD's you can send post them at my site.The best pic will become the FSSOTW (week).

I'll be gone for the next week though, I'm heading to Michigan to see the rest of my family.

Good deal, I'll look forward to more Doors CS suggestions and bug reports when you return, then. 🙂

Bug report about GUIRTextMultiline:
One can click in empty areas and the cursor will be halfway on a line and can be moved outside of the input area. In addition, the cursor will occasionally be in the middle of a character rather than between characters.
Screenie:
A third bug, which I have trouble consistently replicating but have nonetheless encountered multiple times, is that the beginning of the contents of the input area can be made to display elsewhere than the top-left screen corner, and garbage is displayed before it. Sometime the garbage covers the whole area (or seems to clear it) and the actual beginning cannot be seen.

Well, when testing my upcoming TI-MAIL program, I came across a little (huge) bug..


First, I broke the program, then when I pressed Goto (this was under the parser hook) The Screen Froze on the 1 and 2 that are next to the Quit and goto. Finally, I managed to turn off the calc, and when I turned on, RAM CLEAR

You should allow manipulation of data in the DCS parser like in Axe. I'd be pretty cool to use the FileOpen/Save/SaveAs routines in Basic.A good way to practice using the DCS's AP sytem.

I had to "research" which commands are which relying only on the knowledge that DoorsCS uses sum( for it's commands.After about 200 crashes, here's what I got...

Code:


Any luck on the filtering system? 😕

Empty areas of a text box? I'll try to replicate that, but I'd love a screenie if possible. 🙂
Duplicated. It seems the problem is the last character of the line up offscreen, which ends in "i" ("if written in variable-width..."). The cursor movement routines are acting as if that i is on this line. The display routines are acting like it's on the previous line. Scrolling up makes it clear that it's supposed to be on the previous line. That should manifest itself somewhere in the cursor line-end/line-begin estimation where it refers to an offscreen line.

This sounds very very weird; I'd love a more complete description of it, if possible. You mean the contents are offset from their correct onscreen location, but are otherwise rendered in proper line and character order?

i noticed that your using DocDE6
does the same problem exist in DocDE7?

It does indeed. Both of those programs are just using the built-in Doors CS text input routines, rather than having to have their own text input routines (an improvement that saves thousands of bytes, by the way); since that set of routines has not been significantly modified since DCS 6.1, the same issue would exist in Doors CS 6.1 and Doors CS 6.7 beta, Doc DE 6 and Doc DE 7.

CalcDude, I've started looking at these issues; I'd appreciate extra information if you get a chance.

Qazz, can you think of anything else about the situation that might narrow it down? For example in what way you broke it (do you mean broke as in break as in ERR:BREAK?).

That's how I'm understanding it. DCS shouldn't be showing that ERR:BREAK, right?

You could see the first bug at the very beginning of the screenshot I took. Unfortunately, I didn't get it outside of the input area that time.
As for the third bug, yes, but in that empty area there's garbage.

Kerm, I broke it during netural execution

Ah, I see that now, I'll try to replicate it. 🙂
Interesting. I'm making some progress on tracking down the second of the three errors.

Comic: It certainly shows the ERR:BREAK, but with the custom DCS error handler. 🙂

Edit: I have a preliminary theory as to the mode of failure of bug #2. I think my underlying method of calculating the end of the previous line is flawed; I'm starting to test a possible alternative.

Fabulous work, as always! Just checked out the libs (on my new TI-84+SE) and they are stunning. I guess this means that Doors CS 7.0 is in the close future.

However, a quick bug I found.
1. Made folder
2. Entered said folder
3. Opened side menu by right clicking
4. Clicked the back arrow

This crashed it. Should be simple to fix.

Aha, replicated, nicely done. Actually, it only worked for me when I moved a program into the folder and then right clicked on it, between your steps 2 and 3. 🙂 I'll look into this.

I tried the same thing, both with the program inside, and without. I only had the error with the program inside. Although, when I did it without a program inside, it took about an entire minute to return back to the home screen.

Very strange. I'll try to track this down; I can only assume that something in the Properties menu (the right-click menu) is overwriting one of the variables that the desktop needs.