Kerm, I was looking through the DCS_SDK, trying to find info on how the DCS AP feature handles clicking on AP files and opening the file in the viewer. When you enter the viewer program, are the pointers to the AP file already returned, or do they have to be retrieved...Can you elaborate a bit on that side of things?

I'll start with some code that I stole from my platformer that loads levels from AP or from normal places.
Code:
I figured this all out at one point, but now I am just going off of code and (potentially) faulty knowledge. If you open a program that has the same AP type, it will run this program at APStart. The pointer to the actual program data is at (IX+0). (IX-10) and (IX-9) are the size bytes, and (IX- through (IX-1) are all header details. If you had an associated program that looked like:
Code:
(Stolen type code, for my Platformer, inb4 confusion), you could read out the name using something like:
Code:

Does ix (and then hl) point to the size word, or to the data? Will I need to jump the size word and the type byte?

First you have to set up your program header so DCS will know which kinds of APs you handle and load your title, program icon, and AP file icons appropriately. The Apstart entry point is an alternative entry point for your program if someone has opened an AP from the desktop

Code:

Holy hell dude, Pastebin please. http://pastebin.com/xhYHDCVe

You also must provide callbacks to Open/Save/Save As AP routines so that they can ask your code to handle saving and loading for them. The DCS Wiki documents exactly what you need to do, but you're also welcome to piece it together based on the code to my iPaint program, which I've posted here.

More specifically, you need an entrypoint that your program starts at (instead of $9d95) when Doors CS has a pending file being opened from Doors CS itself with your program as the viewer. No special hook is required when your program calls FileOpen or FileSaveAs.

I think this is one of my last questions:



If I am changing the size of the file, do I need to update de AND bc, or just de?

That's a tricky question. Once FileOpen (or the APStart entry point) returns you those values, it isn't tracking them anymore. If you change the size of the file, it's important that you change the value AT de, and you should probably change bc for your own sake, but just changing bc of course won't change anything in memory or let Doors CS know anything new.

Let me just verify:

FileSaveAs is used to create a new file, using the GUI.
FileSave is used to save a file, when you are editing an already existing file.

*Are these the most practical purposes?
**Is there a way, code-wise, to determine which function to call, when ready to save?

Incorrect. Once you're editing an already-existing file, you should not call anything additional. You're responsible for using insertmem/delmem and updating the size word, but should not call anything. FileSave is like FileSaveAs, in that it creates a *new* file, except that it doesn't use the GUI.

Kerm, do you mind if I use your "file open", "file save", and "file new" icon sprites from DocDE7 in one of my own programs.

ACagliano, not at all! Assuming that you're using them with the Doors CS AP system, that is.

A bit off topic, but are there any updates to DCS7.1, Gossamer, or DUSB? Also, I may have asked you before, but is it possible to make a program that can act like the a chat client and go on aim, gmail chat, fb, and send sms messages?

Possible, yes, you should make it. Doors CS 7.2 Beta 2 is the latest version, and it has a new dUSB version. Gossamer has not been recently updated.

Question: In the DCS functions GUIRByteInt and GUIRWordInt, what value to I read to see what the current value of the spinner is.

Assuming that you already understand how to use GUIFindFirst, GUIFindThis, and GUIFindNext to search through the GUI stack, you need to offset 3 bytes from the beginning of the element's pointer to pass the size and type storage, then as per (for example) the wiki page on GUIRByteInt, you skip two bytes to get to the initial (actual) value. It's the same for GUIRWordInt, although the value you end up at is two bytes, not one.

I was wondering, in programs where you need to consistently call the GUI Mouse, can you just put the ld hl,0 and call GUIMouse in a subroutine and just jp to it whenever? Since it acts as a jp itself, it just be a clean navigation.

I see no reason at all not to do that.

Based on the double negative , I'm assuming that means I can. lol. jk. Thanks.

Edit: Sorry to keep pestering you with this stuff, but it's my first time doing heavy usage of that... what does "group" mean in the GUIRRadio and GUIRCheckBox.

Yes, you can, and indeed should to save some space! Please continue asking questions; I can't know what's unclear if you don't ask, and I want people to create awesome GUI programs. You're of course welcome to (please) edit the DCS wiki with anything new you learn that you think other people should know and is missing or poorly explained. For GUIRRadio, group defines which radio buttons get un-selected when any radio button gets selected. For example:


Code:


The first three radio buttons would be in Group 0, and the last four in Group 1. You want "Robot" to get unselected when you select "Male", but you don't want "TI-84+" to get unselected when you choose "Male". Makes sense?

Also, it's more or less meaningless for checkboxes. I usually put each one in a separate group, but it doesn't change any functionality at this point.

Kool. Suddenly the cryptic becomes less cryptic. Thanks.