PDA

View Full Version : Undocumented commands etc.


Peter Boks
11-16-2005, 12:57 PM
A wile ago I received a macro from our ME10 reseller that repaired differences in pensizes.
In this macro they used the qualifier "POINTER (INQ 2)" to select an element.

For example:
INQ_ELEM P1
DELETE POINTER (INQ 2)

This qualifier turned out to be undocumented.
My questions to you all:
Can anybody tell me why they are undocumented?
Are they going to disapear in the future?
Should I use them in my macros or not?
and last but not least:
Do you have more of these examples about undocumented commands etc.

Wolfgang
11-18-2005, 11:35 AM
It's a real unique identifier to an element. If you would have used (inq 101) instead, which is a real x,y point the delete might have found another element at the same x,y point.

but:
INQ_ELEM P1
DELETE POINTER (INQ 2)
DELETE POINTER (INQ 2)

might cause a problem.

Such kind of pointers are in use in the Annotation module. Ask your CoCreate support center whether it will be documented (and supported) in the future.

clausb
11-20-2005, 12:46 PM
Undocumented functionality is undocumented for a reason.

Sometimes, the reason simply is that the feature isn't ready for prime-time yet, but will be in some future version. However, the presence of an undocumented feature is not a commitment from CoCreate to implement the full-scaled and documented version at any point in the future.

Sometimes, an undocumented function only works in a very narrow set of circumstances, i.e. you should only use it if you know EXACTLY what it does and how it works and what side-effects it has, i.e. usually only if you happen to be a member of the OSDD development team. Otherwise, you're running a potential risk of damaging your data and not even know about it.

Or sometimes, somebody just left a feature in the code or inadvertedly exposed it even though it isn't complete - or maybe it is even slightly buggy!

Is there a way to tell which case applies for any given "undocumented function"? Not really, unless you can discuss it with the programmer. It's really a case-by-case decision.

Are those undocumented feature going away in the future? Yes, this can and will happen. So at some point, your macro code which builds on undocumented code will simply fail to execute.

But that's just the best case. Alternatively, the feature might remain in the code, but isn't maintained for some reason, and if you continue to use it, your code LOOKS as if it still works, but internally damages data or creates inconsistent states.

So should you use an undocumented function in your macro? You can probably draw some conclusions from the above; I'd advise against it. Instead, contact CoCreate support and tell them that you need certain functionality. They are in much better position to find out for you whether certain things can be done with the existing code, whether any workaround exists, and, in extreme cases, how "safe" it is to use specific undocumented features. Or, if there is no good way to accomplish what you want, they can put it on the OSDD feature list for future releases.

Claus

John Scheffel
02-15-2006, 01:54 PM
Here's one I came across recently. I was trying to find a way to determine if a variable name was defined or already existed. A search of this forum turned up a macro for doing it, but it was fairly clumsy using TRAP_ERROR and a call of the macro.

In the Drafting Help Programming Reference there is actually a section under commands starting with "U" called "Undocumented Keywords". Under there I found the command MACRO_EXISTS. This can be used in boolean expressions to determine if a Macro or Variable name already exists. For example:

IF (NOT MACRO_EXISTS 'My_var_name')
LET My_var_name 'some value'
END_IF

As expected, MACRO_EXISTS returns 1 if the name exists, otherwise it returns 0. In this case the use is to determine if a variable has been predefined before the macro was called, and if not set it to a default value.

There are some other interesting sounding keywords in this section but no details on what they do or how to use them. One which caught my eye was PUTENV. Since GETENV returns the value of an environment variable, I assumed this one would set an environment variable, but I tried several syntax options and could not make it work. Maybe it only worked in Unix.

GiorgioL
02-15-2006, 10:18 PM
John,

let ans (putenv "variable=value")

display (getenv "variable")

where variable is the name to variable to se, value is the value.

Regards. GiorgioL

John Scheffel
02-16-2006, 10:02 AM
let ans (putenv "variable=value")

display (getenv "variable")
Thanks for posting the info. Interesting. I never would have guessed that syntax since most Drafting commands don't use = for assignment. I was trying sytnax similar to LET such as:

PUTENV 'variable' 'value'
PUTENV variable 'value'

Also interesting that it seems to require the parenthesis, just using the putenv command as follows did not work.

PUTENV "variable=value"

When I tried your example the resulting value of variable ans was 0, so I guess it is some type of error/success code.

Under Windows it seems to set the variable only for the Drafting process and it's children, it does not actually create a new Windows environment variable which is part of the current Windows environment or stored in the registry as a permanent variable. Still, it might be useful for calling macros which use GETENV to change the value they will use.