Nope, sorry if it happens again ill see what I can do to show you

I have a 2 bug reports,

1) I think it might be the xLIB hook, but when I run a Basic program from the home screen, the graph screen clears
2) After a Basic error when running from the home screen, the graph screen is cleared and the error box used the DoorsCS error handler is drawn at the top left corner of the gbuf.

The first one happened to me O_o

Is this bad? Would you prefer the graphscreen to be left intact? I guess there might be some programs that modify some existing contents of the graphscreen. I'll fix this.

Good call, I'll fix that too, and I'll remember to mark the gbuf as dirty.

*bump* I must be getting more lax about bump rules or something.

Anyway, I fixed both of those issues, the former by reusing and (ab)using the graphDraw,(iy+graphDirty) flag to differentiate between programs runs from Homerun and those run from the Doors CS desktop. I also fixed the latter problem with a simple manipulation of the same flag. Next on my agenda is to stare at the issue of a limited number of programs on the Doors CS desktop, and trying to see if I can't resolve that.

Edit: Examined the reported problems in Doors CS 6.2 and lower with high numbers of programs in a single folder, successfully traced to CALCnet2, verified by comparison with Doors CS 6.2. Temporarily placed on Un-Reproducible / Inactive bug list until/unless I get a chance to pick up CALCnet again.

*bump*

RunProg vector is all fixed up! Luckily I was able to do a lot of code reuse, so it's only an extra few bytes for the vector and branch. Check it out in action:

Here's the code I made to check for correct filetypes when opening from the APStart or FileOpen.Just realized it already copies the name to op1 for both, duh...




Code:

Anak, that's pretty nice! Wouldn't it be better if it looked directly at the header of the APMain program though, including its count for the number of valid filetypes? I'll see if I can optimize this a bit more.

Thats what it does Kerm!

It checks for ALL the valid filetype using the #-of-type byte in a djnz loop.If you put the datastart in IX and the #-of-type byte in DE and call the APChkOpen, you can do a *silent* open.

Ah, perfect. Although it's just now occurring to me, wouldn't it make more sense if Doors CS would simply hide everything incompatible from the FileOpen dialog?

You could push de upon calling FileOpen, shorten the DCS FileOpen routine to only output the datastart in IX to save mem, pop de, and then append the code from APChkOpen to the end. You'll get the same output with less work and mem.

What if a person creates a program to edit any AP program? Then hiding wouldn't be such a good idea work.

Yeah, but then people might be frustrated clicking on a file and not having it open (which granted is already the case, since I don't filter by filetype). You don't think fixing the problem from the source would be the better solution?

I didn't say that, I just stated what would you do if a person wanted to open any filetype...

Come to think of it, you should make a checkbox to turn on/off the filter.So if someone else creates a new program with text data, you could possibly open it with DocDE or ProgPad?Almost like a reverse-compatibility thing, like how you can open a application by dragging and dropping it in notepad.



Code:

Please don't ignore my CoolText...


Aww, |)@^^~ !+, im banned again... I hate myself...

I wonder what'll happen if I change the time settings on my pc...

Just for you:

http://www.cemetech.net/doorscs/docs/source7/apguis.asm