Hi, not sure if this counts as a DCSE Bug, or just me missing a trick. But it's an enquiry that I think needs a bit of backstory to make sense.
When I was using the TI-85 I formed the habit of using lowercase names for programs whose only raison d'etre was to be called as subroutines by other programs. This was to keep them all tidily out of the way at the end of the EXEC menu. Then with the 84+SE and now CSE the lowercase wasn't available to me so I always began subroutine program names with <theta>, for exactly the same reason.
Now I have Doors installed [fantastic resource! Many thanks for making it available!] I thought I may as well Archive and Hide all of these subs (for when I'm working outDoors), and stick them all in their own folder, so as not to clutter the Doors Desktop. However, when I try to do any of these things, Doors replaces the theta character with A. If I try renaming the program inDoors, to reinstate its original name, the theta key produces E instead.
The options seem to be:
1. Could DCSE accept the character theta in a filename? I imagine there's probably some good reason why it seems not to.
2. I could rename these subs to something DCSE accepts, then hide them (the reason for wanting the theta to begin with no longer existing). However, this would mean I'd have to edit all the main programs to call the new subroutine name at each instance.
3. There's already a way round this, but I don't know what it is yet!

Incidentally, the enable lowercase is a wonderful feature to me, because of my TI-85 background. It irked me somewhat when TI disabled part of the character set for Basic programming with the 84 family: all my programs seemed to be SHOUTING whenever text was to be displayed. So many thanks for that too. Is it possible (not high priority I suppose) for lowercase to be enabled within filenames too?

Hi! This won't answer your question but if you aren't familiar with this trick already you can list your required sub-routines at the start of your main program and DCS will automatically unarchive them and archive them; I'd imagine this is also ported over to DCS8.

Hopefully someone comes along and actually answers your question

Thanks for the reply. I remember reading that page about a week ago, but don't see the usefulness. Surely if Doors can run programs without unarchiving them, there'd be no need for the trick you mention? I always suspect I'm missing something, because I'm so new to all the skills I'm beginning to learn from Cemetech.

This is a bug. I will put in a fix right now so that the theta key will produce a theta in alpha [A] mode.

Doors CSE would be fine with it, but the TI-OS has serious problems with variables named with lowercase letters, including refusing to let you run programs with lowercase letters in their names. Therefore, to save confusion among users, I disallowed renaming programs to use lowercase names.

Actually, because of a variety of factors, I chose not to include that feature in Doors CSE 8. Sorry.

Edit: Implemented the theta key in my local build. Let me know if you need this ASAP, and I will email it to you; otherwise it will be in the next released version, which will probably be 8.1.

Many thanks! I was prepared to contemplate option 2 from my post above, but thought it better to ask here first in case there was a better alternative. Perhaps I've been the only member using theta in filenames, so nobody ever noticed before! To create a fix specially for me seems an undeserved privilege. I'm happy to wait for the scheduled release of 8.1, I've got plenty to do reading your books and learning about the calculator, as well as working, so tinkering with my file structure can wait!
Am I right in thinking the feature mentioned by ComicIDIOT was not included in 8.0 because HomeRun renders it irrelevant?

This may not be much of a bug but it is interesting. With the latest version of both Doors CSE (8.0.1 Build 1339) and TI's Transformation Graphing App (v4.01), there is a message that pops up.
1. First run Doors CSE.
2. Exit out of Doors CSE and run the Transformation App.

This is a screenshot of the message.


It's interesting that they acknowledge of this wonderful application (Doors CSE).

I can get that error too, although then Transfrm app seems to run anyway. But it's as though the calculator isn't sure whether Doors quit or not.
Yesterday I had 3 anomalies cropping up at once:
Programs ending with a Stop command would act as though they had a ClrHome command right after the Stop; the MathPrint shortcuts on the F keys didn't come up; the StatWizards wouldn't appear either.
So I wondered what could have caused all this to change, thought DCSE was the only thing really different I'd done, so I ran the App and quit it using Clear. This removed all those faults, but the one mentioned by Electromagnet8 still occurs.
Is quitting from the Y= menu different than quitting with Clear? What kind of footprint does Doors leave when it's not running?

Doors CSE does not actively run any code when it doesn't look like it's running, but it installs a number of hooks, TI-OS lingo for short sections of code that the OS executes when certain events happen.
1) If you have Doors CSE set to run on power-on, it install a keyhook. This keyhook detects when you are shutting off the calculator so that Doors CSE will run immediately when you turn it back on.
2) If you have HomeRun enabled, a parserhook is installed that intercepts running programs from the homescreen.
3) If you have xLIBC/Celtic II enabled, a second parser hook runs inside TI-BASIC programs, catching real( and det( calls.
4) If you have the enhanced BASIC editor enabled, a menuhook is installed that detects when you're entering the BASIC editor, intercepts it, and opens the editor itself with a different setup.

Can you guys try disabling each of these features and see which one(s) make the Transfrm warning go away? The warning is appearing because Transfrm wants to use one of those hooks, and the programmers for some reason didn't make it capable of chaining. Doors CSE can chain, so you can install Transfrm, then Doors CSE, and everything should work.

I have found by disabling one by one of each of the options in Doors CSE itself that there is only one hook that affects the Transfrm App. It is the improved BASIC Editor hook. If this is enabled, the message pops up when trying to run Transfrm. If it is not enabled, the app executes without a message.

Then it's the menuhook that Transfrm is unhappy about. Have you tried doing things in the opposite direction: Enabling the Transfrm App, and then activating the Improved BASIC Editor? Since DCSE chains, it might work.

After the Transfrm app is activated, you can run the app although I think I see a glitch (Edit: It only happened a few times then it stopped. When trying to graph more than one equation, a message pops up saying that it will only graph up to 3 plots and 1 equation (normal). After you press graph, it will graph the first equation. Upon finishing, it will redirect you to Doors CSE even if you did not press any buttons).

Even with the Transfrm app running, you can still access the improved BASIC editor after you enable it. After enabling it, both Transfrm and Doors CSE works normally. But if you go to the app menu and try to run Transfrm again, the message will pop up this time. If you select the first option (Quit Transfrm app), it will not quit it. If you select the second option, it will disable Doors CSE's hooks.

With the Transfrm app running, you can not launch Doors CSE with the [On][Prgm] hook if you select the option to quit all APPS under Doors CSE when prompted while trying to run Transfrm.

*bump
I have run into a bug. Although it is rare (I have encountered this three separate times), I do have to press the reset button on the back in order to fix this.
First, I run a program, usually Basic. Afterwards, while trying to edit in the Improved Basic Editor, an error message quickly pops up. It is Error: ? and the only option is to quit. While in this message, the calculator only responds to [1], [Enter], and [Clear]. The first two keys just yield a refresh of the screen, while [Clear] briefly returns to the program editor. After about half a second, it will return to the error message again. I can catch sight of the program name, which reads PROGRAM: dcsasmex, which is not the actual program name. The only way to escape from the error message is to press the reset button.

Can you come up with a program that reliably does this? Based on the symptoms, I am pretty confident you are running this BASIC program from Archive.

I have not found a specific program that triggers this but they are all in Archive.

Makes sense. Please let me know if you come across something reliable that lets you narrow down the causes, for example using xLIBC or other Doors CSE libraries in the programs and so on.

I will try over time and test the numerous posibilities. Like I have said, I have only encountered this three times since using DCSE since it was released, so it may be awhile before I trigger it again.

That's understandable; thanks for keeping your eye out for it. I asked specifically about xLIBC because I thought I triggered the bug you described once or twice while creating Flappy Bird Color, but I didn't really pay much attention to it at that point.

I have been able to trigger this Error: ? bug twice today: one on my calculator during school and one on jsTIfied (a first).
Both were triggered when I tried to edit a pure Basic program. Both had DoorCSE on them.
First instance: After recieving a program from a TI-84+SE, I decided to edit it. I added about about 7 lines of code that just displayed text then paused. I was able to run it two or three times. Here is where something happened. After an entering a value for an input, the prgmNAME flashed on the screen. Immediately after, an Archived Error message popped up and requested the two options. I selected the Goto and the Improved Basic Editor appeared. The following is the same as the Error: ?.
Second instance: On jsTIfied, I had a two pure Basic programs (the same program as above but different code). Both of these were Unarchived. I tried to Edit one and it immediately yeilded the Error: ?.

Feature request for Celtic sprite library. Would be nice to be able to toggle off the inverse of the sprite.

That is true ^
Although for now, I'm just throwing an inverted rectangle function over my sprite, it works.