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!