Determine which objects are visible in a viewport

[Greg S]

For several types of symbols, we provide a key for where to find them in terms of sheet and viewport (similar to a detail call-out, but on a worksheet). Up until this point, we've been adding the sheet number manually to the symbol's record. The problem is that this can be time consuming and is not dynamic in the case that the sheet number, viewport instances, or symbols change.

I can't seem to find a function in the API that would allow us to automatically find which viewports or sheets a symbol is displayed on. Is there a way to accomplish this? 

 

Example of what I'm trying to accomplish:

We draw a junction box on a floor plan that is 4' above the floor. This would place the object on a floor plan, area detail, and elevation viewport. The symbol's record field or OIP field is populated with all sheet numbers this object can be found on. 

Down the road, the junction box is moved lower and an elevation is no longer needed so that viewport is removed. The field on the object is automatically updated to show it's only on the floor plan and area detail now. 

 

All the methods I can think of are pretty computationally expensive ( find the bounds of every viewport crop and compare to the symbols coordinates for example). 

[Pat Stanford]

I don't think there is going to be an automatic way to do this. You would need to run a script to update the data. Theoretically you could put the script into a WS RunScript function so it will run when the worksheet is recalculated, but I don't know if there is a way to force the script to run before the rest of the WS recalculates. So you might need to recalculate twice.

 

Using a criteria of a LOC plus some indicator of what symbols (probably an attached record) you want to process.  

 

Assuming you have a "reasonable" number of viewports, the update should not take more than a few seconds to process. Using the criteria method to get the objects in each viewport should be relatively fast compared to doing a manual comparison.

 

WARNING: Pseudocode follows:

 

Procedure Test;

  Procedure Execute(Hd1:Handle);
	Begin
	SetRField(Hd1, MyRec, MyField, Concat(GetRField(Hd1, MyRec, MyField), '; ', Name1));
	End;

Begin
Deselectall;
SelectObj(T=Viewport);
L1:=NumSObj;

{delete the data from MyRec.MyField for all objects so it can be recreated}

Hand1:=FSObject; {get first viewport}

While Hand1<>Nil do
Begin
  Name1:=GetName(Hand1);
  ForEachObject (Execute, (((Loc=Name1) & (R in ['MyRec'])));
  Hand1:=NextSObj(Hand1);
End;
End;

Run(Test);

 

[Greg S]

Pat, assuming I understand the strategy this is genius! I think running it as a WS script is perfectly fine - especially if it can run properly during a recalculation or two. 

Am I understanding correctly that the ForEachObject call is able to evaluate objects within the selected view port?

[Pat Stanford]

ForEachObject runs a sub-procedure (in the example it is named Execute [I used to use Do_It (without the underscore) until someone had a sans serif font turned on and thought I was calling them a dolt] for every object that meets the criteria specified.

 

So if you use a criteria of a certain record being attached and that object being present in a certain LOC you should get a reasonable number of objects actually being passed to Execute.

 

I have not tested, but I think you can just use the VP name with the LOC and not have to mess with getting the crop object, but I am not certain.

[Greg S]

Ha! Execute is a fine procedure name!

 

This is at least a great starting point. Thank you sir!

[Pat Stanford]

As you get stuck, ask more questions. I and others are happy to help on scripts for those who want to learn.

 

[Greg S]

@Pat Stanford Interesting discovery after some testing, it seems that when LOC is used as criteria, it only works within the same type of layer from what I can tell.

 

What worked

I drew a rectangle around a symbol and gave the name: 'recBoundary'. Doing this, LOC associated the boundary and symbol even if they were on different design layers.

 

Things broke when I tried the same with the view port OIP name.

Where things fell apart

• Using the view port name as the LOC criteria
• Using recBoundary as the view port's crop object.
  • This did associate with annotation elements in the same view port.
  • This did not catch the design layer symbol's square...but it did catch the symbol's text for some reason?
• Placing recBoundary directly on the sheet layer. LOC associated the view port and the annotation objects, but nothing from the design layers (except the symbol text, again)

Would love anyone's thoughts on this dilemma. Am I missing something, or is this a bug?

 

See attached file for what I'm working with.

On sheet T101, the worksheet shows the results of the LOC comparisons. 

 

LOC_Test_VW26.vwx

Edited Saturday at 12:06 AM by Greg S
corrected first sentence "Design Layer" > "Layer"

[Pat Stanford]

I was wrong. You can't use a Viewport as a LOC location. Sure would be a nice feature.

 

Not a bug, but just something that does not work.

 

There might be some sort of work arounds, but nothing that feels like it will be "automatic"

 

Simplest might be to use the Viewport Edit Design Layer with the Show Reference Crop Object box checked. That will get you an object on the design layer to use as the LOC.  But you will need to name the reference object and set its attributes to be invisible.

 

And I don't know how you create the reference object via a script.

 

Sorry.

[Greg S]

No worries Pat! In some further testing, is seems that LOC is based on (forgive my probably incorrect nomenclature) finding things relative to the origin. In the case of the sheet layer, I could get the view port to work but only because it was over the center of the sheet and the symbol I had inserted on the design layer was also at the origin. If I moved the symbol away from the origin, LOC no longer found it, but it did find the objects that composed the symbol because those were created at the origin of that symbol... If I edited the symbol and shifted it's components away form the symbol origin, LOC lost them. Not sure I completely understand the goings on in the background, but this is the best explanation I have ATM. 

 

Either case, I'll look into some other options. I appreciate your help!