Topic Title

Here is my read on this. It would be nice if we could get some feedback from DataCAd to confirm this and make any corrections needed. The DCAL manual is for the original DCAL Macro language. IN the revised version for Delphi (D4D) the parameters are changing to accomodate the DLL format. DataCAD calls the dll method "Main" and drives the macro operations based upon the current state. Each time the main method is called it is channeled to a different group of methods. The macro determines what is next by passing a return value (IWant). It appears that DataCad returns the Iwant value in the parameter DCADState in the next loop. The unit UInterfacesRecords identifies a series of record types used as Arguments in the Parg variable. These arguments corespond to a number of routines, such as getpoint, getdistance, getangle, etc..., that get user input from DataCad mouse and keyboard input. I am not quite clear on what exactly distinguishes the need to pass the Parg arguments for these routines rather than accessing other values through DataCad variables/properties such as the current linecolor, linetype etc... In other words, why was it necessary to change the oringal parameters used in calling getpoint to the new ones in D4D?

All the DataCAD API's that have the following calling arguments:

Code: Select allVAR iwant: wantType
OR
var retval: wanttype


return a values that are already defined in DataCAD. You should not worry about what value it is returning and let it be assigned to Result of main. These values tell DataCAD what it has to do next. Internally DataCAD also has Main routine that handles all these values that DataCAD has assigned. You simply are making a call to those functions using the API's provided.

In old DCAL, there was no way to telling if the user really changed the value when getdis is called or if he pressed any key. You could not specify if you need absolute value. All these parameters are stored in getdis record. getdis is yet another DataCAD's state which need to know how the calling function needs to be processed and thus it uses getdisarg as pargs. When getdis returns back to the calling state you can check the result of getdisarg.

Let us say you as a programmer writes a macro and decide that the return value of main is 4079 at some-point. How should DataCAD rely if 4079 is actually a valid value or not? You might not have defined any case statement for 4079 in you Main routine. DataCAD knows only that it has to look for 'Main' routine in DCAL and the valid range is 4000 to 4099. As long as the range index is valid it will simply make a call to Main routine of the DCAL with 4079, irregardless 4079 exists or doesn't. It is you as a programmer who decides how to handle 4079 case.
In the same way if you call any DataCAD API and DataCAD returns a value and expects you pass it back to DataCAD, it is DataCAD's responsibility on how to handle that value. At this point DataCAD guarantees that the returned value will not be between 4000 and 4099. Any other value returned by DataCAD has some meaning and DataCAD will handle it accordingly. Every-time you will make a call to Getpoint, retval will always be equal to 3. If you change the retval from 3 to some other value, you change the meaning on what has to occur next. That can lead to application crashing.
From my perspective what really is important is what the API does as opposed to what value is returned by the API.
When you call getpoint or getdis or getang or any api that requires input from user, the control of program flow is controlled by DataCAD and not by dcal program. As long as you are making the right call on what to do next , DataCAD will return you the correct value and assumes that you return him the back the correct value.
If you want to prompt a user for the angle, you cannot call getdis and expect DataCAD to return you angle. You will have to call getang. If you make a call to getdis followed by getang immediately, last one overrides the previous one and DataCAD will only make a call to getang. DataCAD can processes only one command at a time.
I might be sounding as if I am rude, but I am not. I am just trying to make it simpler to understand.

I am parsing Devinder’s previous entry:

D:

Let us say you as a programmer writes a macro and decide that the return value of main is 4079 at some-point. How should DataCAD rely if 4079 is actually a valid value or not? You might not have defined any case statement for 4079 in you Main routine. DataCad knows only that it has to look for 'Main' routine in DCAL and the valid range is 4000 to 4099. As long as the range index is valid it will simply make a call to Main routine of the DCAL with 4079, irregardless 4079 exists or doesn't. It is you as a programmer who decides how to handle 4079 case.

Joe: It is my understanding that the range is between XDcalStateBegin = 8100 and XDcalStateEnd = 8200 and that the macro author directs the program flow through the management of the case statement for the variable DCALState. DataCad controls the action loop for the program and each time the macro is entered by DataCad it calls “Main”. The macro then performs a function depending upon the DCAL state value and returns a result value of the type IWant. In the next loop, DataCad passes the IWant value back to the Macro using the DCALState parameter. In this way the macro is telling itself what it should do during the next loop. I assume that a return value of XDone (0) terminates the macro. (Is this after a call to “Main” with the act value of Alast?)

D:

In the same way if you call any DataCAD API and DataCAD returns a value and expects you pass it back to DataCAD, it is DataCAD's responsibility on how to handle that value. At this point DataCAD guarantees that the returned value will not be between 4000 and 4099. Any other value returned by DataCAD has some meaning and DataCAD will handle it accordingly.

Joe: Are there specific instances where the macro is expected to return a value back to DataCad?

D:

Every-time you will make a call to Getpoint, retval will always be equal to 3. If you change the retval from 3 to some other value, you change the meaning on what has to occur next. That can lead to application crashing.
From my perspective what really is important is what the API does as opposed to what value is returned by the API.
When you call getpoint or getdis or getang or any api that requires input from user, the control of program flow is controlled by DataCAD and not by dcal program. As long as you are making the right call on what to do next , DataCAD will return you the correct value and assumes that you return him the back the correct value.

Joe: I am not certain what you mean by “the correct value”? Do you mean the next DCALStae the macro wishes to implement in the next loop?

D:

If you want to prompt a user for the angle, you cannot call getdis and expect DataCAD to return you angle. You will have to call getang. If you make a call to getdis followed by getang immediately, last one overrides the previous one and DataCAD will only make a call to getang. DataCAD can processes only one command at a time.

Joe: I read this last statement as saying that the user must redefine the Pargs for the input procedure it wishes DataCad to make, and places the appropriate input method call within the code to be used in the next loop for the DCALState.

D:

I might be sounding as if I am rude, but I am not. I am just trying to make it simpler to understand.

Joe: I don’t believe anyone thinks you are rude, on the contrary, I am grateful that you are monitoring and responding in the forum. For me the real difficulty is that there is no overview of the process to refer to, only a couple of code examples. Although I think I’ve got most of it, I am still trying to understand some of the basics and have not yet gotten to the point where I am ready to do detailed testing using a macro within DataCad. For me, the most basic unanswered question is why must the data be passed using pargs rather than through parameters in the calling Interface functions as was done in DCAL version 1?

I sincerely hope that a manual is being prepared that clarifies some of the basics, clearly, the current dialog reinforces the need for an description of the overall operation of the dll macros.

Thanks for Your Help!

...I don’t believe anyone thinks you [Devinder] are rude, on the contrary, I am grateful that you are monitoring and responding in the forum.

I agree in full what you're saying. Thank You Devinder for your availability.

I sincerely hope that a manual is being prepared that clarifies some of the basics, clearly, the current dialog reinforces the need for an description of the overall operation of the dll macros.

I am commited to translate it into the portuguese language, and I am sure several others will want to do the same. (the instructions and helping informations, not the codes of course).

Thanks,
Miguel

Yes, you are are on right track. Just want to add something. Even though l.getp looks meaningless, it does some action behind the scenes on its call. DataCAD stores the address location of that variable so that before it re-enters Main routine, it can flush the data to that variable location. Without DataCAD knowing which variable to modify the results in, DataCAD cannot pick any arbitrary location to flush the Data out to. In the same way if DataCAD were to flush out Data in some memory how would you know where the data has been written. Thus l.getp is not meaningless.