Confused Level Display / Level Manager windows - not used levels displayed in bold !?

Hello,

I am a little confused about how the levels are displayed in the level manager and level display windows.

Normally, it is so that use levels are highlighted in bold!

But now I see that even unused levels are in bold?

Now I have found out that the corresponding level is not used in the actual MODEL, but in other MODELS of this drawing.
In the Level Manager I opened the properties window of the affected level and could see in the last tab "Usage" that the other models are listed there as used.

In my opinion, if I am on a specific Model where I open the level display window, it is not right that the display refers to all models of the DGN !!

At the moment I work on a specific model and I think that, checking whether used or not, should be limited on this model.

Or am I wrong?

Regards

Raphael

Parents
  • I understand the highlight is to help in knowing what to display off.

    I would like to see highlighted text for active in current model

    BIG BLACK DOT for active in all models  (I see need for both.

    Ustn since 1988
    SS4 - i7-3.45Ghz-16 Gb-250/1Tb/1Tb-Win8.1-64b

    Eric D. Milberger
    Architect + Master Planner + BIM

    Senior  Master Planner NASA - Marshall Space Flight Center

    The Milberger Architectural Group, llc

  • Hi all, and many thanks for posting

    @ Tamicca

    Yes you are right on this and I know that for Microstation there is only one level table for all models of one DGN. That´s one difference to Autocad, where you can have multiple layer states on different model spaces of one file.

    There is no problem with visualisation of the dot for used or not used levels. The problem is how the level information (the complete line of the level with all activated information) will be displayed. I mean how the description line "font" of this level will be displayed, in bold or not! 

    @ Adrian

    Yes this works without problems, but it has nothing to do with the described problem. In your case all level lines are displayed in bold, because all this shown levels are used.

    In my case, where all levels are displayed in the level display window (no filter), there are some level description lines displayed in bolded font also when this level is not used in the actual model.

    @ Eric

    " I understand the highlight is to help in knowing what to display off. "     not really understand what you're meaning?

    " I would like to see highlighted text for active in current model. BIG BLACK DOT for active in all models "

    I agree and it would be also my wish that we could distinguish whether a level is used in the current model or in any other !!

    @ all

    The level display window responds as follows:

    (bold concerns the Level description line, dot means the dot under usage)

    - Not Bold & no dot: Level is not used on any model.

    - Bold & no dot: Level is not used in current model but in any other model.

    - Bold & dot: There is the fly in the ointment!
    In my opinion this does not fit into the logic. Double information will be given, but it cannot clearly be identified.
    The “dot” clearly indicates whether a level in the current model is used or not. This works reliably and is logical.
    The “dot” relates effectively only on the current model, but “bolded” is not clearly assigned:

    -       Levels used in the current model: “dot” shown

    -       Level unused in the current model: “dot” not shown

    -       But “bold” will appear in both cases: Level is used in current model or only in any other model !!

    So summarized what is clearly shown:

    - Level is not used on any model (not bold & no dot)
    - Level is not used in the current model but in any other model (bold & no dot)
    - Level is used in the current model but maybe also in any other model (bold & dot)

    Here I'm missing:
    - Level is used in the current model and not in any other model (only dot)
    - Level is used in any other model but not in the current model (only bold)

    in which case the constellation "bold & dot" should not exist!

    It may be a little confusing and irrelevant to some.

    Unfortunately this behavior bothers me again and again. Perhaps it is also due to the projects and working method.

    Probably nobody can really help me in this case, but at least, I have now found out for myself how the level display windows works and what exactly bothers me.

    Thanks
    Greeting
    Raphael

  • Hi Chris,

    In MS, it´s not possible to use a separate level table for each model of a DGN, so all existing and required levels must be in one single level table.

    IMO that’s a reason why model based a better overview of the used levels will be important.

    A case where I would want a better overview .....

    For example, when splitting an existing drawing on several models, I would like this.

    For example, if from a common level table you want only using individual levels on specific models, that means divide the levels into groups and assign them to the models, it would be helpful.

    As it appears at the moment, I´m always again confused when check whether a level is used on another model as the active one, which would mean that there still are elements on it.

    Of course I can also examine each specific model for elements, but a good and quick overview could be done through the level display window.

    As described in the last post, it´s not possible to identify whether a level is ONLY used in the current model.

    An example scenario:

    I work on “model 3” and only on this model elements on “level 10” are allowed. In the level display window the “dot” indicates that this level is used on the current model (OK) in addition the text is “bold” because this level is used in this file.

    But it´s not recognizable if “level 10” is used ONLY in the current model.

    Or am I wrong?

    Hope I could explain it without further confuse :)

    Regards

    Raphael

  • >As it appears at the moment, I´m always again confused when check whether a level is used on another model as the active one, which would mean that there still are elements on it.

    There is a way to obtain this information; check the Usage tab of the Level Properties dialog.  Alternatively, use the level usage keyin (Command format is : level usage [file:file-spec] level-spec). 

    Given that the level could be used in tens of models, the type of information you are looking for appears best communicated in a list; however that's not to say the current method we use to communicate usage in the Level Manager and Level Display can't be improved. 

    Thanks,

    Chris



  • Chris,

    Thanks for the tipp, but this is what I had written in the main post. By this way I found out that the other models are listed as used on a specific level.

    I agree there are one ore more possibilities to see the needed Informations, but if I can have this on a window like the "Level Display" who always been opened.......

    that will be smarter :)

    "however that's not to say the current method we use to communicate usage in the Level Manager and Level Display can't be improved."

    For improvements we are always grateful...

    who knows.... :)

    Thanks

    Raphael

  • What a about a open circle rather than a filled bullet to indicate "Used in File" vs  "Used in model"

  • Unknown said:

     however that's not to say the current method we use to communicate usage in the Level Manager and Level Display can't be improved

    Thanks,

    Chris

    Indeed it can:

    (a) A capability (say a "mode"?) to display used Levels on a per Model basis could worth solid gold.

    Why may you ask: Well...exploit this rather simple pedestal bridge where Models are used as Refs and/or as Shared Cells depending on some assembly/component way of thinking (although Microstation is not designed that way, far from it). You can easily see that "components" have their own mind about their Levels and displaying Level usage "per dgn basis" is utterly confusing and unproductive. Of course in this type of design attempting to use Level dgnlibs and the likes is like 3rd marriage.

    (b) all drop down Level lists should operate on the same manner with regard Level usage.

    (c) multi Leveled Shared Cells (as is the norm in component design) must be allowed to display ALL used Levels. As it is :  well....you know...

    (d) Some say that Levels, Level libs  and Level driven 3d CAD is the future. I say that is the past. Why way you ask. Well...imagine (in a few years from now) a generative (or algorithmic/scripted) way to design 3d objects - on a per 3d object basis....

    So with this (rather simplistic) bridge on hand .... the 1M question is: can you effectively handle what's going on?

    Notify if you need some more complex cases.

    best, Peter

    3d_layput1.dgn
Reply
  • Unknown said:

     however that's not to say the current method we use to communicate usage in the Level Manager and Level Display can't be improved

    Thanks,

    Chris

    Indeed it can:

    (a) A capability (say a "mode"?) to display used Levels on a per Model basis could worth solid gold.

    Why may you ask: Well...exploit this rather simple pedestal bridge where Models are used as Refs and/or as Shared Cells depending on some assembly/component way of thinking (although Microstation is not designed that way, far from it). You can easily see that "components" have their own mind about their Levels and displaying Level usage "per dgn basis" is utterly confusing and unproductive. Of course in this type of design attempting to use Level dgnlibs and the likes is like 3rd marriage.

    (b) all drop down Level lists should operate on the same manner with regard Level usage.

    (c) multi Leveled Shared Cells (as is the norm in component design) must be allowed to display ALL used Levels. As it is :  well....you know...

    (d) Some say that Levels, Level libs  and Level driven 3d CAD is the future. I say that is the past. Why way you ask. Well...imagine (in a few years from now) a generative (or algorithmic/scripted) way to design 3d objects - on a per 3d object basis....

    So with this (rather simplistic) bridge on hand .... the 1M question is: can you effectively handle what's going on?

    Notify if you need some more complex cases.

    best, Peter

    3d_layput1.dgn
Children