SetCallBackInval for Set(D)Select calls

[caravanio]

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?

[Pat Stanford]

I don't know for sure if this will work for you or not, but Joshua Benghiat posted the following to the Vectorscript email list last year:

 

Quote

In that case, you may find this tidbit useful:

You can also use SetPref(9873,TRUE) to prevent a screen redraw when the view is changed but then you MUST call SetPref(9873,FALSE) after you set the view back. You will see the largest speed increase in a 3D view from this.


-Josh

 

[caravanio]

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?

 

[Pat Stanford]

The other option to reduce the visible drawing/selecting/flashing while the script is running is to move the view to a location away from the drawing area. Maybe 10 screen areas right/left/up/down, wherever you would not expect there to be objects drawing. At the end of the script move the view back.

 

This can often increase the speed as well since I think VW is smart enough to not draw handles/selection for objects outside of the screen area.

 

Another possibility, that I have not tried, would be to make a group and set it to invisible and then create the other objects in the group. At the end either set the visibility to on or ungroup the object.

[caravanio]

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.

[Pat Stanford]

I agree that workarounds are not the best way, but if there is not a proper factory authorized way to do what you want you have 2 choices. You can sit and wait until they decide that the functionality you need is required and add it to the program. Or, 2, you can look and see if you  can find a different way to accomplish the functionality you need.

 

Perhaps if you actually told us more about what you are really trying to do we could give better answers. It is frustrating to try and help and then repeated be told, "there is another restriction also that I didn't tell you about."

 

From the last post what I get is that it is a requirement that the screen stay the same until all the processing is done and then you get a single update. Is that correct? If so, why does it need to stay visible? What is the user going to do with that info while they are locked out of working on the drawing because the script is running?

 

If you need to let them know it is running you could translate to a place that displayed a message like, "Script running. Your drawing will update as soon as the script is compete." Then translate back after it is done.

 

Your call since you know the requirements, but just think about if the requirements make sense. I am on another list for another program and have a programmer who is killing the list because he refuses to ask his client if any of the requirement he was given NINE years ago have changed, so he is still trying to use outdated versions of things because he won't ask if he can use current versions. 

 

If the above comes off as harsh, I apologize. I think I am grumpy today. At least my family is telling me I am.  ;-)

[caravanio]

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.

[Pat Stanford]

The question then becomes is SetCallBackInval broken and not operating properly, or do we (you and I and probably everyone except the person who wrote this command) have a misunderstanding of what is and is not a CallBack?

 

There have been a number of cases where I have been very insistent that something was not working properly and then had it explained to me that my understanding was wrong. One case was with Handles.  There are calls for FinLayer returning the first object in the Layer and Object returning the first object in the drawing.  In my mind, by getting FObject, you should be able to travers the entire document list. Unfortunately, the traversal (NextObj) stops at the end of the first layer. Not at all what I expected, but when fully explained, I understand that it is the documentation that is bad, not the FObject/NextObj calls.  Perhaps something similar here.

 

It you want this functionality, I would file a bug (that may come back WAD, Working As Designed) and also file an enhancement request for the actual functionality that you want. Please provide a way to lock the screen view so it is not updated during the running of a script. This functionality should be able to be turned off manually in the script or automatically upon completion of the script.  With the bug, include a file with as simple of script as possible that will show the screen refreshing during the operation of the script after using SetCallBackInval.

 

Good luck. Let me know what else I can help with.

 

[caravanio]

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.

[Pat Stanford]

And just how do you know this? What documentation from Vectorworks, Inc. do you have that states this?

 

I understand what a callback is and that based on the name, I would expect this to be the functionality. Based on my long time history with VW and Vectorscript/MiniPascal, I doubt that this is true. 

 

The select/dselect routines are far older than the SDK. It is very likely that some of the newer functions will respond as you expect, but there are likely many other VS functions that just have never gotten updated to properly use callbacks.

 

Expecting functionality based strictly on names in VS is often a losing battle. ;-)