[VectorScript: Detect self-intersecting polygon/polylines]

Hello, all. Looking at the VectorScript function reference I see no functions that could tell whether a given polygon/polyline is self-intersecting. The only function that is told that it 

Quote

"... Should remove self-intersecting segments from the result. ..."

is the VS:OffsetPoly. But I don't want to see if a polygon/polyline is self intersecting as a side effect of an operation that actively acts on the selected object but just a read-only operation whether it is self-intersecting or not. Any suggestions are welcome.

[SetCallBackInval for Set(D)Select calls]

A callback is a function that is as the name states "called back" when a given operation finishes, etc. In the context of Vectorworks this should be every SDK function. All the C++ SDK functions are now called through a global callback pointer, thus all of them are probably considered callbacks where they should just be classified as SDK functions. So, SetCallBackInval should prevent/allow each SDK function from redrawing the screen. Would collect more info about the SetCallBackInval and will share it. About the bug report - would file such after I completely understand and verify the effects that SetCallBackInval is expected to produce.

[SetCallBackInval for Set(D)Select calls]

No worry, thanks for being so active responder on the topic. What I actually want to achieve is exactly what the:

SetCallBackInval( FALSE );

is meant to achieve: leave the drawing as is without letting the user know of the underyling object manipulations, creations, deletions, selection state alternation, etc. taking place. Hence, the requirement for not changing the view. Just don't want to provide the user with "disco" effects while the script is ongoing and provide him/her with the actual final result. Currently, the only problem I have is where the changes of the selected state are visible. The temporary objects problem was defeated using the already implemented opacity workaround.

[SetCallBackInval for Set(D)Select calls]

Translating the view outside the currently visible region is not an option since a requirement is that the view is not changed. Creating the new objects in a hidden group is needless since what is currently been done now as a workaround is that each newly created object is being hidden. What I was thinking of is somehow to print screen the whole visible drawing area or save it somehow in a viewport, so that whatever operations happen are obscured by the always visible print of the original objects and their selected states. It would have been much better if the available Vectorworks options worked as they were supposed to. Hacking and workarounding is not the best discipline one should always get accustomed to when dealing with any problems.

[SetCallBackInval for Set(D)Select calls]

SetPref(9873,TRUE)

did nothing - again objects are seen how they are drawn on the go while the procedure is running. Tried creating a simplified scenario reproducing the problem but cannot replicate the processing delays even with:

Wait( ... );

Even when creating 10000 objects in a row and then playing with the selected state of each of them Vectorworks doesn't redraw the screen anywhere during the whole operation, probably since it is too busy doing all the object creation and (de)selection operations in a row. It is obvious that 9873 is an undocumented application preference. Is it possible that all those hidden preferences are well documented?

 

[SetCallBackInval for Set(D)Select calls]

Hello, all. The problem:

Take a Vectorscript menu command at hand as an example that does a lot of SetSelect/SetDSelect (1) calls, creates and deletes many temporary and not temporary objects (2). Searching for a Vectorworks functionality that disables drawing refresh due to any drawing/selection operations done programmatically I've found SetCallBackInval. Its documentation states that:

Quote

This should be used if you need to create temporary objects for calculation purposes and do not want the screen to be redrawn as a result.

 

Thing is that it doesn't work. Setting it to any value the net effect is the same:

1. objects created by the routine become visible as soon as they are created
2. selected/deselected objects' border highlight appears and disappears on the go

 

A workaround to hide the temporarily created objects while the routine is running, is to set their opacity to 0. This solves partially problem (2), since temporarily deleted objects should be handled in a different way - by scheduling them for deletion at the moment which the drawing should be redrawn. Another problem still persists - (1) or how to remove the flashing effect when an object is selected/deselected during the time the routine is running.

 

Any ideas why the SetCallBackInval doesn't work and how to achieve the desired effect?

[Execution context lost upon transition from tool back to menu-command]

When one implements a VS menu-command plug-in and uses either:

1) GetPt or some of its variants

2) CallTool

... pressing ESC, any other key that activates different than the active tool or activating another tool by clicking with the mouse button on it in the given tool palette, causes the menu-command to loose its execution context. The execution of the menu-command is interrupted at the point of the GetPt/GetPt3D/GetPtL/GetPtL3D/CallTool call. CallTool's documentation states that:

After the tool has been used VectorWorks will revert back to the previously active tool.

Probably this is valid only for tool plug-ins.

Here's a sample script:

PROCEDURE Main;
VAR
pt: POINT;

BEGIN
AlrtDialog( 'Pick a location...' );
GetPt( pt.x, pt.y );
       {any code starting from this point does not get executed if ESC or another tool chaning key is pressed or the active tool is changed via a mouse click}
AlrtDialog( concat( 'Location: (', Num2Str( 3, pt.x ), ', ', Num2Str( 3, pt.y ), ')' ) );
END;
RUN(Main);

Obviously, this is a bug. Is there a way/workaround to go back to menu-command's execution context after changing the desired tool with another one?