[CE VBA] Select shared cells on level

Hi,

brenks said:

Also, I'm using Map PowerView so I'm not sure if same happens in Microstation.

Please, respect the best practices and specify a version of the used product exactly. There were many version of MicroStation (as well as OpenCities Map) released, so it's important to know what version is used.

Also, when you decide to do not ask in Geospatial Programming forum (which is recommended for OCM products), but here in MicroStation one, specify both OCM version and on which PowerPlatform version it's based.

brenks said:

Is this some change in VBA or is this a bug?

It looks like bug, because the level is set, but it's ignored in combination with shared cell instances. I recommend to create Service Request for this issue.

brenks said:

Workaround is to test level of every shared cell in file.

Yes ... technically it's "to test the level of share cell instance header".

It's exactly what is done internally (when the scanning works correctly), so I do not see any problem in such solution.

brenks said:

this is sample of code

There are some (many?) useless lines, duplicating default functionality and producing worse code:

• Dim esk As New ElementScanCriteria
  Set esk = New ElementScanCriteria
  ... the 2nd line is useless
• esk.IncludeLevel ActiveDesignFile.Levels.Item("8_tocke")
  can be shortened to esk.IncludeLevel ActiveDesignFile.Levels("8_tocke")
• num = 0
  ... the number is always initialized to 0, so useless
• ee.Reset
  ... is useless, because ElementEnumerator is always returned by Scan in an initial position
• If ee.Current.IsSharedCellElement Then
  ... no reason to test the element type when it's already controlled by ElementScanCriteria

Regards,

  Jan

Thanks Jan,

It's probably a bug and I created SR alreday. I just wanted to know if anybody encounterd this.

• ee.Reset
  ... is useless, because ElementEnumerator is always returned by Scan in an initial position

Thank you for pointing out .We have enumerator resets which will be soon deleted :)

Other pointed out lines are there for testing purposes.

Thanks Jan,

It's probably a bug and I created SR alreday. I just wanted to know if anybody encounterd this.

• ee.Reset
  ... is useless, because ElementEnumerator is always returned by Scan in an initial position

Thank you for pointing out .We have enumerator resets which will be soon deleted :)

Other pointed out lines are there for testing purposes.

We have identified a problem in the OpenCities Map software as-relates to Shared Cells , and are working on a fix for it.

Hi Dan,

Dan Weston said:

We have identified a problem in the OpenCities Map software as-relates to Shared Cells

thanks for the info.

On the other hand, the level-based scan criteria does not work with Shared cells in plain MicroStation too, so I guess it's something in PowerPlatform API ;-)

Regards,

  Jan

Hi Jan Šlegr,

FYI. Artur Goldsweer is working with the Civil team on this and will provide an update for any related Defects for base MicroStation/PowerPlatform.

[RH-20210720 UPDATE: BUG 673741 has been filed to address this issue]

Thank you and HTH,
Bob

Jan Šlegr said:

On the other hand, the level-based scan criteria does not work with Shared cells in plain MicroStation too, so I guess it's something in PowerPlatform API ;-)

Keep in mind that unless a shared cell instance has it's level override set, the level of the instance isn't used and the shared cell definition elements display using their stored levels.

Hi Brien,

Brien Bastings said:

unless a shared cell instance has it's level override set, the level of the instance isn't used

thanks for "internal implementation" note.

On the other hand, I think VBA users are not aware of these features (as not described anywhere, as far as I know), and thei approach is simpler and more straightforward: When level is assigned to shared cell instance and displayed in MicroStation GUI ...

... how to search these instances?

BTW The cell on the picture is identified at level "moje_vrstva" when the header is selected (or displayed in Element Properties dialog), because it was active level when the cell was placed. But the cell content is placed on another level, as defined in shared cell definition. Is it the situation you talk about, when "level override" is mentioned?

Regards,

  Jan

The details tab shows the overrides.

If you use the "Change Attributes" tool on a shared cell instance it will set the appropriate override flags.

If I remember correctly, back in V7 when there were only 63 levels, a "level mask" was stored on the shared cell instance so that the scanner could efficiently check level criteria.

Since the number of levels is no longer fixed, there is no longer a level mask stored on the element. As such shared cells are no longer rejected on level criteria by the scanner (unless I assume, but did not test, the level override is set).

Shared cells have a further complication called "relative levels" where the effective level of the sc def components is determined by using the component's level id as an offset from the instance's level; this really only applies/works for shared cells that came from V7 where levels are 0-63.

Since a shared cell can display components on different levels, it's not clear to me what "select shared cells on a particular level" means. If you have hundreds of instances of a particular shared cell, you certainly don't want to be reading the sc definition hundreds of times (once for each instance) in order to check the component levels.

-B

Hi Brien,

as usually, thanks a lot for the detailed explanation!

Brien Bastings said:

it's not clear to me what "select shared cells on a particular level" means.

This thread is not my question, but what I see in my customers, is they mean the level displayed in Element Properties dialog. In other words, the level of the cell header (active level when the cell was placed):

I agree that, when the cell is spread over more levels, such searching may not be logical, because it does not query the cell content, but e.g. my customers use typically cell where everything is in one level. And even when spread over more levels, the visibility is controlled by this one level, so it's intuitive.

With regards,

  Jan