this is sample of code that I use in v8i for selecting shared cell elements on specified level. I'm trying to migrate code to CE but it seems that all shared cells from all levels are found. Workaround is to test level of every shared cell in file.Is this some change in VBA or is this a bug? Also, I'm using Map PowerView so I'm not sure if same happens in Microstation.
Dim ee As ElementEnumerator
Dim esk As New ElementScanCriteria
Set esk = New ElementScanCriteria
Set ee = ActiveModelReference.Scan(esk)
Dim num As Long
num = 0
If ee.Current.IsSharedCellElement Then
num = num + 1
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:
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Answer Verified By: brenks
It's probably a bug and I created SR alreday. I just wanted to know if anybody encounterd this.
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.
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 ;-)
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.
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?
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.
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.