Thanks! I'll update the RC2 download before I go to bed tonight.

I implemented the header parsing change necessary to allow 34 bytes of BASIC code before the OpenLib/ExecLib code. I did the testing I could, and everything seemed fine. Also, I discovered the following bugs:

- [+] scrolls like [-]
- [+] and [-] and [up] from page 1 sets the scrollbar to page 3 but displays page 2.

Edit: Both fixed.

OCD issues:
1. The title of the program on the info popup is a few pixels too low and it overlaps with the file size.
Solution: move title text up a few pixels.
2. When typing something for copy, rename, and new program/folder, the text goes down too far and the bottom of the rectangle disappears.
Solution: make rectangle go down more by a few pixels.

Bugs/suggestions:

Not sure it's intentional or not, but are you supposed to be able to make two folders with the exact same name? They seem to be treated separately, but that can get confusing, and may be bad for future API's.

Also, when renaming a folder, or file, you can enter in characters OTHER than A-Z. For example,

UP = }
DOWN = i (lowercase I)
LEFT = ;
RIGHT = i
STAT = ₁

and there are others. Most of them just put out a 0 (zero), but not all.

Id take a screenshot of both of the above in my DCS build, but I cant get a screenshot. I tried TI-Connect, but it wont do it. Do I really have to recreate everything in an emulator and do it that way?

These were both the result of textEraseBelow,(iy+textFlags) being set when Doors CSE started, probably because you ran a program that uses the det(12) Hybrid BASIC call. Doors CSE now explicitly cleans up that flag.

That's intentional. I'll leave it to users to decide whether or not they want to confuse themselves. Folders with the same name do not cause Doors CSE any problems, regardless of whether they have the same parent folder or not.

No need to screenshot; I am well-aware of this issue. I've been assuming up to now that it's not really something that needs to be fixed, as it doesn't break anything to have weird symbols in program names (other than hiding those programs from the TI-OS PRGM menu). If you think it looks unpolished from a useability standpoint, I can see what needs to be done to prevent that behavior.

Yeah, it kinda looks strange, and like something was just overlooked. Doesnt hurt anything, thats true, but just looks unpolished, like you said. Im using my CSE for my math homework right now, and Im flipping in and out of various apps I wrote for different problems. So far everything seems to be working well. I can test the header details later this evening.....unless you have something new for me to test with....

It seems like arrow keys could be put to better use navigating within the text entry.

Something that simple, I didnt even think about. I agree, that would be nice. Mess up the 8th character, and have to redo the whole name because you cant go back one space and retype that one letter....ughhhh

They could, but I'm not going to implement text insertion this late in the game, at least for 8.0. Anyway, I fixed all the errant keys:
- [F1]-[F5] ([Y=] through [GRAPH]) type nothing
- Arrow keys type nothing
- [XTθn] types X
- All other non-letter keys type A in ALPHA mode
- All other non-number keys type 0 in non-ALPHA mode

So. Other than xLIBC code, I'm completely out of bug and feature fixes for Doors CSE 8.0.

Do you know if the new version of xLIBC will add the ability of display numerical values (from a real var) using the real(6 command and if it will be possible to change the offset of the two GRAM buffers to make side scrolling games easier? I remember that tr1p1ea talked about possibly implementing this, but I wasn't sure if it was a long way off and official.

You will be able to display integers from -9999 to 9999. I haven't heard anything about him implementing that feature.

I just tried out DCSE RC2 with the DrawFilledCircle command. I typed in: real(7,12,80,60,10,189,1) and it drew a lavender-bluish ellipse with the major axis on the y-axis, appeared for about .5 seconds and then gave the barcode-style screen, with all keypresses giving a white screen for the duration of the hold. Pressing [ON] twice did the trick.
I did not lose anything and I repeated this 3 times. Maybe I'm not typing it in correctly (centered at 80,60 , radius of 10, color 189).

[Edit] Also returns the same condition with DrawCircle (Empty)

That black-and-white barcode is called the LCD's panic mode, and it happens when pixels are drawn outside of the 320x240-pixel GRAM area. Sounds like you might have uncovered an xLIBC bug for tr1p1ea to look into.

So I can use x- and y- coordinates outside of the graphing [160x260]?

[Edit]: Another shape bug
Drawing a filled rectangle:

Code:

I run the program once and the rectangle is drawn correctly. I ran it a second time and the rectangle is drawn with the x-coor at about 240ish. A third time run is correct, a fourth is weird. A fifth is correct, etc. Also, during all runs, the yellow running circle is displayed in normal position frozen and the white pause circle is rotating above it, squished in between the top of the screen. [Enter] ends the program.

Did your enable half-resolution mode first?

Btw to draw stuff the Y coordinates are 0-120, not 0-240 nor 0-260. The screen is in 160x240 mode, but xLIB scales things up vertically.

Ok the drawCircle bug was fixed a few days ago, i just forgot to reset the window to what the TIOS likes :X.

As for the rectangle issue, i will investigate.

DJ: You can display -9999 to 9999 with the drawString command. This is for TIOS variables and due to restrictions on real( arguments. You technically can use the uservars to display numbers up -32768 to 32767 through some tricks.

As for the other feature im not sure if i will be able to get it in before release. Maybe i might be able to add something quick but i DESPERATELY need ALL xLIB functions checked end-to-end.

Ok thanks for the info. I was asking before continuing development on my game, in case the new feature would be ready very soon. For now I'll go the same way as my other game. (sort-of, since I need to recode a lot of stuff)

*bump* Any bug reports on xLIBC or Doors CSE, guys? We're aiming at a Tuesday, November 5, 2013 release for Doors CSE 8.0.

Not yet. Im going to test xLIBC tonight for a bit, but so far, no complaints.

Great, and thanks for doing xLIBC testing. I know that tr1p1ea is anxious to make sure all the routines get a workout before the release.