As Simon mentioned in previous post here, I am working on an application, which I am developing under the code name "Map Invoker". It will generate random towns, from small little hamlets to large walled cities. I've been concentrating on the algorithm side and am truely quite a ways towards a "feature complete" logic set.
So Simon was correct in stating that "He’s gone beyond proof of concept". Soon I will be turning from generation to the interface so that all the parameters that I've included in the algorithms are exposed to the user so that the user can create an incredable range of different towns.
Once the paramter inputs are down and tested, then we will be looking into adding all the "garnish" that makes programs like this come alive. So if you have any ideas, practical or "pie in the sky", I'd love to here them. Either post your idea or email me at: SAUNDERL (at) HOTMAIL (dot) COM.
Where to go to learn how to extend Campaign Cartographer 3 (CC3)
Monday, October 25, 2010
Code name: Map Invoker
Tuesday, September 28, 2010
The Spiral Command - In Three Parts (Part #1)
The Spiral Command - In Three Parts (Part #1)
In this post and the next two posts, I will be building a spiral command. In this post we will be dealing with the algorithm. When we are done with this post, we will have a command that draws a spiral that would have 20 loops if it started in the middle, but we also told the algorithm to not draw the innermost 10 loops. We have also hard currently coded the command to draw the spiral with a distance of 10 between each loop.
I will be using the name MYSPIRALM for this temporary command. When finished, this will be the command for the macro version.
Note: There is a naming convention that states if you have both a dialog driven command and a comand that is all command line for macros, the macro version ends with an M.
Hardcoded values:
Friday, August 20, 2010MyLine Command (A Complete Example)
We have finally reached the point where we can produce an entire example. In my previous post I explained how, conceptually, this command will work. Now, here is the actual code for the command along with a lot of comments.
I have also copied and commented out the definitions for the relevant elements that we are going to create.
I hope that you fire up Visual Studio and try building this code; if you are impatient though and want to just run it, here
In this post and the next two posts, I will be building a spiral command. In this post we will be dealing with the algorithm. When we are done with this post, we will have a command that draws a spiral that would have 20 loops if it started in the middle, but we also told the algorithm to not draw the innermost 10 loops. We have also hard currently coded the command to draw the spiral with a distance of 10 between each loop.
I will be using the name MYSPIRALM for this temporary command. When finished, this will be the command for the macro version.
Note: There is a naming convention that states if you have both a dialog driven command and a comand that is all command line for macros, the macro version ends with an M.
Hardcoded values:
- Distance Between Loops: 10
- Number of Inner Loops Not Drawn: 10
- Total Number of Loops: 20
- Clockwise/Counter Clockwise: Clockwise
- Growth Between Loops: None
Friday, August 20, 2010MyLine Command (A Complete Example)
We have finally reached the point where we can produce an entire example. In my previous post I explained how, conceptually, this command will work. Now, here is the actual code for the command along with a lot of comments.
I have also copied and commented out the definitions for the relevant elements that we are going to create.
I hope that you fire up Visual Studio and try building this code; if you are impatient though and want to just run it, here
Code Snippet - MySpiralM Command
- ////////////////////////////////////////////////////////////////////////////
- //
- // File Name: MySpiral.cpp
- // Written by: L. Lee Saunders
- // (C)2010 Beer & Pretzel Games
- // All rights reserved
- //
- ////////////////////////////////////////////////////////////////////////////
- #include <windows.h>
- #include <math.h>
- extern "C"
- {
- #include <xp.h>
- #include <Extend/Mysvc.h>
- }
- extern XP MyXP;
- ////////////////////////////////////////////////////////////////////////////
- void XPCALL DrawSpiral (int Result,int Result2,int Result3);
- GPOINT2 CenterPoint;
- FORMST(lpszCenterPoint,"Center Point:\0")
- RDATA PCenterReq =
- { sizeof(RDATA), RD_2DC, NULL, RDF_C, (DWORD*)&CenterPoint,
- (DWORD*)&lpszCenterPoint, RDC_XH, DrawSpiral, NULL, NULL, 0, NULL, 0};
- ////////////////////////////////////////////////////////////////////////////
- ////////////////////////////////////////////////////////////////////////////
- void XPCALL MySpiralM (void)
- {
- ReqData(&PCenterReq); //get center point
- }
- ////////////////////////////////////////////////////////////////////////////
- ////////////////////////////////////////////////////////////////////////////
- void XPCALL DrawSpiral (int Result,int Result2,int Result3)
- {
- if (Result != X_OK) { CmdEnd(); return; }
- float Growth = 1;
- float LoopDistance = 10;
- int Rotations = 20;
- int InnerLoopsToSkip = 10;
- const char * Direction = "0\0";
- pENTREC pEntRec; //Create a new drawing database entity
- float CenterX = CenterPoint.x;
- float CenterY = CenterPoint.y;
- int iDirection;
- MarkUndo();
- // Insert an empty path into the drawing list
- pEntRec=DLApndE(NULL, ET_PATH2, sizeof(PATH2)+sizeof(GPOINT2));
- // Get the common stuff
- GetCStuff(pEntRec);
- // Set the smoothing to Parabolic Blend (through-point)
- pEntRec->Path.Path.SmType = SM_PB;
- // Set the centerpoint of the spiral
- pEntRec->Path.Path.Nodes[0].x = CenterPoint.x;
- pEntRec->Path.Path.Nodes[0].y = CenterPoint.y;
- // How many points to draw per circle
- const double STEPS_PER_ROTATION = 50;
- // Amount to add to angle at each step
- double increment = M_PI/STEPS_PER_ROTATION; // Splitting up
- double theta = 2*M_PI*InnerLoopsToSkip; // This allows for an open area
- // inside the spiral
- // Determines if the loops rotates clockwise or counter clockwise
- iDirection = strcmp(Direction, "0") == 0 ? 1 : -1;
- while(theta < (Rotations * 2) * M_PI)
- {
- pEntRec=DLResize(pEntRec, pEntRec->Path.CStuff.ERLen +
- sizeof(GPOINT2));
- pEntRec->Path.Path.Nodes[pEntRec->Path.Path.Count].x=(float)
- (CenterX + theta * cos(theta) * (1/(M_PI * 2)) * LoopDistance *
- iDirection);
- pEntRec->Path.Path.Nodes[pEntRec->Path.Path.Count].y=(float)
- (CenterY + theta * sin(theta) * (1/(M_PI * 2)) * LoopDistance);
- pEntRec->Path.Path.EParm=(float)pEntRec->Path.Path.Count;
- pEntRec->Path.Path.Count++;
- LoopDistance = LoopDistance * Growth;
- theta = theta + increment; //If theta grows faster then increment,
- //it will have wider spaces between each loop
- }
- EDraw(pEntRec); //Draw our line
- ShowChanges(); //Needed for CC3 to "Show Changes" to the DB
- CmdEnd();
- return;
- }
- ////////////////////////////////////////////////////////////////////////////
Thursday, September 2, 2010
How to walk the "Drawing List"
In trying to decide what element of CC3 XP programming I was going to blog about next, I started to re-read all of the old posts on the cc2-dev-l email list @ groups.yahoo.com.
Wow, I had forgotten how much valuable information was out there. If you have the time (And it will take a bit of time) just start at the beginning and read through the threads. I promise that you will learn something – I did!
I found a request by Linda Kekumu. It seemed that she had a large number of maps that had lots of Notes attached to them and they were wrong. She needed a quick way to clear out all the notes on a map, instead of manually removing them one at a time. Peter responded with this dash of code.
The reason I selected it for this post is that it is probably the smallest piece of code that displays how to use DLScan. Now DLScan does exactly as the name says, it scans the “Drawing List” (i.e. the drawing database) and calls a function for every “identified” element. I say “identified” because there are times when you only want to look at a subset of the entire Drawing List.
In this new XP command, we scan the Drawing List with the DLS_Std flag, telling DLScan that we want to scan the Drawing List for “all standard all non-erased elements”.
Then in our called function (ClearNotesScan) we check the EType of each identified element (pEntRec) . If the EType equals ET_Note, we know it is a Note and we call DLErase to remove the element from the Drawing List.
So, with this, you can now scan through a map and look at every identified element!
Wow, I had forgotten how much valuable information was out there. If you have the time (And it will take a bit of time) just start at the beginning and read through the threads. I promise that you will learn something – I did!
I found a request by Linda Kekumu. It seemed that she had a large number of maps that had lots of Notes attached to them and they were wrong. She needed a quick way to clear out all the notes on a map, instead of manually removing them one at a time. Peter responded with this dash of code.
The reason I selected it for this post is that it is probably the smallest piece of code that displays how to use DLScan. Now DLScan does exactly as the name says, it scans the “Drawing List” (i.e. the drawing database) and calls a function for every “identified” element. I say “identified” because there are times when you only want to look at a subset of the entire Drawing List.
In this new XP command, we scan the Drawing List with the DLS_Std flag, telling DLScan that we want to scan the Drawing List for “all standard all non-erased elements”.
Then in our called function (ClearNotesScan) we check the EType of each identified element (pEntRec) . If the EType equals ET_Note, we know it is a Note and we call DLErase to remove the element from the Drawing List.
So, with this, you can now scan through a map and look at every identified element!
Code Snippet – MyClearNotes Command
- /////////////////////////////////////////////////////////////////////////////
- //
- // Program: CC3DeveloperBlog.dll
- // File Name: MyClearNotes.cpp
- // Written by Peter Olsson (Copied here by L. Lee Saunders)
- // (C)2010 Beer & Pretzel Games
- // All rights reserved
- //
- /////////////////////////////////////////////////////////////////////////////
- #include <windows.h>
- #include <math.h>
- extern"C"
- {
- #include <xp.h>
- #include <math.h>
- }
- extern XP MyXP;
- /////////////////////////////////////////////////////////////////////////////
- /////////////////////////////////////////////////////////////////////////////
- DWORD XPCALL ClearNotesScan(hDLIST hDList, pENTREC pEntRec, PARM p1, PARM p2)
- {
- //If the Entity Record is of type "Note" then erase the Entity from DL
- if(pEntRec->CStuff.EType==ET_NOTE) { DLErase(pEntRec); }
- return 0;
- }
- /////////////////////////////////////////////////////////////////////////////
- /////////////////////////////////////////////////////////////////////////////
- void XPCALL MyClearNotes(void)
- {
- //Description copied from FCW32.TXT
- //---------------------------------------------------------------
- // ClearSel - Clear All Selection bits
- //---------------------------------------------------------------
- ClearSel();
- //This sets an undo point so that every action after this to the end of
- //the command will be reversed if the user selects UNDO.
- MarkUndo();
- //Drawing list scan. We are interested in only the first three parameters
- // Param #1: Drawing list - If null, it is the main list
- // Param #2: Our Callback function for every identified element in the DL
- // Param #3: DSFlags. How we identify what DL elements we want
- DLScan(NULL, ClearNotesScan, DLS_Std, 0, 0);
- //End the command
- CmdEnd();
- }
- /////////////////////////////////////////////////////////////////////////////
Friday, August 20, 2010
MyLine Command (A Complete Example)
We have finally reached the point where we can produce an entire example. In my previous post I explained how, conceptually, this command will work. Now, here is the actual code for the command along with a lot of comments.
I have also copied and commented out the definitions for the relevant elements that we are going to create.
I hope that you fire up Visual Studio and try building this code; if you are impatient though and want to just run it, here is the dll.
I have also copied and commented out the definitions for the relevant elements that we are going to create.
I hope that you fire up Visual Studio and try building this code; if you are impatient though and want to just run it, here is the dll.
Code Snippet - MyLine Command (A Complete Example)
- ////////////////////////////////////////////////////////////////////////////
- //
- // Written by: L. Lee Saunders
- // Date: 8/15/2010
- // (C)2010 BeerAndPretzelGames.com
- // All rights reserved
- //
- ////////////////////////////////////////////////////////////////////////////
- #include <windows.h>
- extern "C"
- {
- #include <XP.H>
- #include <Extend/Mysvc.h>
- }
- #define XPID 0xF000
- void XPCALL About(void);
- void XPCALL MYLINE(void);
- char CList[]="MYLINE\0";
- PCMDPROC PList[]={About,MYLINE};
- XP MyXP =
- { 0, CList, PList, 0, 0, 0, XPID, 0, 500, 0, 0, 500 };
- ////////////////////////////////////////////////////////////////////////////
- ////////////////////////////////////////////////////////////////////////////
- FORMST(MyAPkt,"BLOG DLL commands:\n\n"
- "\tMYLINE - Duplicating the Line Command #s\n\0")
- void XPCALL About (void)
- {
- FormSt(&MyAPkt,RSC(FD_MsgBox));
- }
- ////////////////////////////////////////////////////////////////////////////
- ////////////////////////////////////////////////////////////////////////////
- void XPCALL MYLINE2 (int Result,int Result2,int Result3);
- void XPCALL MYLINE3 (int Result,int Result2,int Result3);
- //This is the definition of LINE2
- //==========================================================================
- //typedef struct
- //{
- // CSTUFF CStuff; // entity properties
- // GLINE2 Line; // line properties
- //} LINE2;
- //This is the definition of GLINE2
- //==========================================================================
- //typedef struct
- //{
- // GPOINT2 p1; // starting point
- // GPOINT2 p2; // ending point
- //} GLINE2;
- //This is the definition of GPOINT2
- //==========================================================================
- //typedef struct
- //{
- // float x;
- // float y;
- //} GPOINT2;
- //This is the definition of CSTUFF
- //==========================================================================
- //typedef struct
- //{
- // int ERLen; // entity record length
- // unsigned char EType; // entity type code
- // char EFlags; // erase/select bits
- // char EFlags2; // extra flags
- // unsigned char EColor; // entity color
- // unsigned char EColor2; // fill (2nd) color
- // char EThick; // pen thickness 0..25.4 mm
- // short WPlane; // workplane (0 = XY plane)
- // short ELayer; // layer
- // short ELStyle; // line style (0=solid)
- // short GroupID; // group id (0 = not grouped)
- // short EFStyle; // fill style (0=hollow)
- // float LWidth; // line width
- // int Tag; // entity tag id
- //} CSTUFF;
- //This is the working structure that we will use to create all the lines
- LINE2 BuildL = {
- sizeof(LINE2), // entity record length
- ET_LINE2, // entity type code
- 0, // erase/select bits
- 0, // extra flags
- 1, // entity color
- 1, // fill (2nd) color
- 0, // pen thickness 0..25.4 mm
- 0, // workplane (0 = XY plane)
- 1, // layer
- 0, // line style (0=solid)
- 0, // group id (0 = not grouped)
- 0, // fill style (0=hollow)
- 0.0, // line width
- 0, // entity tag id
- 0.0, // starting point: x
- 0.0, // starting point: y
- 1.0, // ending point: x
- 1.0 // ending point: y
- };
- FORMST(lpszFirstPoint,"1st point:\0")
- FORMST(lpszNextPoint,"Next point:\0")
- RDATA P1Req =
- { sizeof(RDATA), RD_2DC, NULL, RDF_C, (DWORD*)&BuildL.Line.p1,
- (DWORD*)&lpszFirstPoint, RDC_XH, MYLINE2, NULL, NULL, 0, NULL, 0};
- RDATA P2Req =
- { sizeof(RDATA), RD_2DC, NULL, RDF_C, (DWORD*)&BuildL.Line.p2,
- (DWORD*)&lpszNextPoint, RDC_RBAND, MYLINE3, NULL, NULL, 0, NULL, 0};
- ////////////////////////////////////////////////////////////////////////////
- ////////////////////////////////////////////////////////////////////////////
- void XPCALL MYLINE (void)
- {
- ReqData(&P1Req); //get first point
- }
- ////////////////////////////////////////////////////////////////////////////
- ////////////////////////////////////////////////////////////////////////////
- void XPCALL MYLINE2 (int Result,int Result2,int Result3)
- {
- if (Result != X_OK) { CmdEnd(); return; } //If we did not get valid info
- MarkUndoAdd(); //Enable Undo
- NewCsrOrg(BuildL.Line.p1.x, BuildL.Line.p1.y); //Set cursor origin
- ReqData(&P2Req); //Get next point
- }
- ////////////////////////////////////////////////////////////////////////////
- ////////////////////////////////////////////////////////////////////////////
- void XPCALL MYLINE3 (int Result,int Result2,int Result3)
- {
- pENTREC pEntRec; //Create a new drawing database entity
- if (Result != X_OK) { CmdEnd(); return; } //If we did not get valid info
- //This gets all the current stuff like current color and assigns it
- //to our line entity.
- GetCStuff(&BuildL.CStuff);
- //Append a copy of our line to the DB and return a pointer to the new
- //entity in the database. We assign it to pEntRec.
- pEntRec=DLApnd(NULL,(pENTREC)&BuildL);
- EDraw(pEntRec); //Draw our line
- ShowChanges(); //Needed for CC3 to "Show Changes" to the DB
- BuildL.Line.p1.x=BuildL.Line.p2.x; //move 2nd x to 1st x
- BuildL.Line.p1.y=BuildL.Line.p2.y; //move 2nd y to 1st y
- NewCsrOrg(BuildL.Line.p1.x,BuildL.Line.p1.y); //Set cursor origin
- ReqData(&P2Req); //Get next point
- }
- ////////////////////////////////////////////////////////////////////////////
- ////////////////// DllMain - XP initialization & Unload code ///////////
- BOOL WINAPI DllMain (HINSTANCE hDLL, DWORD dwReason, LPVOID lpReserved)
- {
- switch (dwReason)
- {
- case DLL_PROCESS_ATTACH:
- {
- MyXP.ModHdl=hDLL;
- XPRegCmd(&MyXP);
- break;
- }
- case DLL_PROCESS_DETACH:
- {
- XPUnregCmd(&MyXP);
- break;
- }
- }
- return TRUE;
- }
- ////////////////////////////////////////////////////////////////////////////
Sunday, August 15, 2010
Beads – How to Wait for Input
[Note: This is copied from the "FastCAD XP Programming Reference" that comes with the XP toolkit. I copied this, with editing only for clarity, because it was so descriptive]
Nowhere in the Windows programming environment will you find a greater need to change your thinking than with regard to getting input.
In Windows, our programs receive messages that inform us of discrete user input - a mouse movement, button click, or a keyboard press. Other than dialog boxes, there is no way provided to wait for a complete word or line of text or other aggregate input in your program and then continue. We must write our program so that each keystroke is processed and then control is returned all the way to Windows.
This means that in a piece of code (creating a text entity, for example) we can not have one procedure that calls another to get a line of text and then continues with the next instruction when it is available, as would be done in a DOS or Unix program. The current position within that first command procedure is normally maintained on the stack, perhaps as a nested chain of procedure calls.
In Windows, after every event (such as a single key press), we have to return all the way up the stack back to Windows! This is why most Windows programs do all of their input through dialog boxes.
The FastCAD solution to this problem is to think of a command as a string of "beads" - little pieces of a command that each do one small part of the overall command, each a piece that can be done in response to an appropriate input event.
Lets take as an example a command to create a line entity. In traditional programming, its logic might be:
LineCommand:
prompt the user for the first point
- Get the first point if there was a problem getting it, end the command
prompt the user for the second point
- Get the second point if there was a problem getting it, end the command
Create the line entity
Append it to the drawing database
Draw the line entity
End the command
In FastCAD, we have an API service, ReqData, that handles data requests. We call ReqData with a packet that tells it about the data request, and then we go back to Windows.
When the data becomes available, ReqData will call another procedure specified in our original request packet to continue with our command. This means that we write our command as a series of procedures, linked together by RDATA packets, each one executing when its data becomes available, and returning to Windows when it needs to wait for more input.
The sequence looks like this:
==========================
Event: Action (Bead procedure):
- LINE function entered
- - Request first point by calling ReqData
- Line function ends
User enters the first request for a point:
Event: Action (Bead procedure):
- Second LINE function entered
- - Did the user cancel the request?
- - - End Command
- - Request second point by calling ReqData
- Second Line function ends
User enters the second request for a point:
Event: Action (Bead procedure):
- Third LINE function entered
- - Did the user cancel the request?
- - - End Command
- - Else
- - - Create the line entity
- - - Append it to the drawing database
- - - Draw the line entity
- - - End Command
- Third Line function ends
The LINE command is implemented in 3 beads, each of which is called in response to a single event, such as a mouse click or a RETURN keypress. The ReqData service provides all of the intermediate beads that track mouse movement and build up strings of characters into words like "LINE" for you.
Next post, we will start to implement the LINE command.
Nowhere in the Windows programming environment will you find a greater need to change your thinking than with regard to getting input.
In Windows, our programs receive messages that inform us of discrete user input - a mouse movement, button click, or a keyboard press. Other than dialog boxes, there is no way provided to wait for a complete word or line of text or other aggregate input in your program and then continue. We must write our program so that each keystroke is processed and then control is returned all the way to Windows.
This means that in a piece of code (creating a text entity, for example) we can not have one procedure that calls another to get a line of text and then continues with the next instruction when it is available, as would be done in a DOS or Unix program. The current position within that first command procedure is normally maintained on the stack, perhaps as a nested chain of procedure calls.
In Windows, after every event (such as a single key press), we have to return all the way up the stack back to Windows! This is why most Windows programs do all of their input through dialog boxes.
The FastCAD solution to this problem is to think of a command as a string of "beads" - little pieces of a command that each do one small part of the overall command, each a piece that can be done in response to an appropriate input event.
Lets take as an example a command to create a line entity. In traditional programming, its logic might be:
LineCommand:
prompt the user for the first point
- Get the first point if there was a problem getting it, end the command
prompt the user for the second point
- Get the second point if there was a problem getting it, end the command
Create the line entity
Append it to the drawing database
Draw the line entity
End the command
In FastCAD, we have an API service, ReqData, that handles data requests. We call ReqData with a packet that tells it about the data request, and then we go back to Windows.
When the data becomes available, ReqData will call another procedure specified in our original request packet to continue with our command. This means that we write our command as a series of procedures, linked together by RDATA packets, each one executing when its data becomes available, and returning to Windows when it needs to wait for more input.
The sequence looks like this:
==========================
Event: Action (Bead procedure):
- LINE function entered
- - Request first point by calling ReqData
- Line function ends
User enters the first request for a point:
Event: Action (Bead procedure):
- Second LINE function entered
- - Did the user cancel the request?
- - - End Command
- - Request second point by calling ReqData
- Second Line function ends
User enters the second request for a point:
Event: Action (Bead procedure):
- Third LINE function entered
- - Did the user cancel the request?
- - - End Command
- - Else
- - - Create the line entity
- - - Append it to the drawing database
- - - Draw the line entity
- - - End Command
- Third Line function ends
The LINE command is implemented in 3 beads, each of which is called in response to a single event, such as a mouse click or a RETURN keypress. The ReqData service provides all of the intermediate beads that track mouse movement and build up strings of characters into words like "LINE" for you.
Next post, we will start to implement the LINE command.
Tuesday, August 3, 2010
Ok, you requested data, now what did you get?
Ok, so you have messed around with the RDATA function and you want to select an element, like a circle. So you create a new RDATA function with the fallowing parameters:
A pEntRec type is a very important type in writing XP's. The pEntRec type is the generic entity pointer that can point to any type of drawing entity. So, if you selected a circle with your RDATA call, pEntRec will point to the the circle entry within the "Drawing Database"
The "Drawing Database" is the collection of all the visible elements in the map. When we select elements, Campaign Cartographer returns a pointer to the selected element in the "Drawing Database".
Once you get a pointer to an entity, you can edit, interrogate or delete it.
Every entity shares some common data - appropriately named: CSTUFF
CStuff is defined as:
For example you have a pEntRec named pENTREC and you want to get the entities color:
- Cursor: RDC_PICK
- Flags: RDF_C
- Type: RD_Pick1
A pEntRec type is a very important type in writing XP's. The pEntRec type is the generic entity pointer that can point to any type of drawing entity. So, if you selected a circle with your RDATA call, pEntRec will point to the the circle entry within the "Drawing Database"
The "Drawing Database" is the collection of all the visible elements in the map. When we select elements, Campaign Cartographer returns a pointer to the selected element in the "Drawing Database".
Once you get a pointer to an entity, you can edit, interrogate or delete it.
Every entity shares some common data - appropriately named: CSTUFF
CStuff is defined as:
Code Snippet - CSTUFF
- typedef struct
- {
- int ERLen; // entity record length
- unsigned char EType; // entity type code
- char EFlags; // erase/select bits
- char EFlags2; // extra flags
- char EColor; // entity color
- char EColor2; // fill (2nd) color
- char EThick; // pen thickness 0..25.4 mm
- short WPlane; // workplane (0 = XY plane)
- short ELayer; // layer
- short ELStyle; // line style (0=solid)
- short GroupID; // group id (0 = not grouped)
- short EFStyle; // fill style (0=hollow)
- float LWidth; // line width
- int Tag; // entity tag id
- } CSTUFF;
For example you have a pEntRec named pENTREC and you want to get the entities color:
pENTREC->CStuff.EColor
Labels:
Campaign Cartographer 3,
CC3,
pEntRec,
RDATA,
XP development
Sunday, July 25, 2010
Requesting data from CC3 - RDATA
Last post I introduced the two most important functions exposed by CC3: RDATA & FORMST.
In this post I'll discuss the internals of RDATA.
Here are the important elements you need to configure for every time you declare an RDATA.
When I first started to write XP's, Super Guru Peter Olsen sent me a little tool that he wrote to automatically generate the RDATA call. When I was preparing for this post, I asked Peter if he still had the app. Well, he did, but he suggested that I create an online version of the tool. So, here is a Silverlight 4 application that generates an RDATA structure for you.
In my next post, I'll use the tool to generate our RDATA and select our first element. Plus, we will start to discuss what it is exactly, that we get back from our ReqData call.
In this post I'll discuss the internals of RDATA.
Here are the important elements you need to configure for every time you declare an RDATA.
- Name - This is simply the name the holds all the separate RDATA elements together
- Type - This is where you declare what kind of data you are requesting
- Flags - These flags are the switches that tweak the RDATA call to do exactly what you want
- Data Store - Where to "put" what you have requested after it has been selected
- Prompt - This is the text that will be displayed to the user
- FormSt declaration - This is where you decide if you want to include the prompt declaration. If you already have exactly the prompt you want already declared, you can reuse it instead of creating a new one
- Cursor - Obviously selecting a single item you want a different cursor than if you want them to type in some text
- Return Procedure
When I first started to write XP's, Super Guru Peter Olsen sent me a little tool that he wrote to automatically generate the RDATA call. When I was preparing for this post, I asked Peter if he still had the app. Well, he did, but he suggested that I create an online version of the tool. So, here is a Silverlight 4 application that generates an RDATA structure for you.
In my next post, I'll use the tool to generate our RDATA and select our first element. Plus, we will start to discuss what it is exactly, that we get back from our ReqData call.
Subscribe to:
Posts (Atom)