How to disable menu in MicroStation CE Update15 using XCommands?

Hi Rajesh Varatharajan,

Do you link ECObjects.lib in your (.mke) project where this method is defined?

HTH,
Bob

Hi Bob,

Thanks for your reply. It works now.

IXCommandCP cmd_ptr = XCommandManager::GetManager().FindXCommandByIconName(L"ViewAttributes");
IXCommand* xcmd = (IXCommand*)cmd_ptr;
xcmd->SetIsEnabled(FALSE);

I am using above code to disable view attributes button in view menu. 
But its not working. Kindly let mw know why?

Regards,

Rajesh Varatharajan

Rajesh Varatharajan said:

But its not working.

What happens, when you rebuild the ribbon? Does it disable the command? In such case the problem is probably in not synchronized state (internal state is different than "command presentation" in ribbon).

Regards,

  Jan

Hi Jan,

We are not doing anything with ribbon. Just we are trying programmatically to disable button. In this way how can we able to achieve it??

SetIsEnabled - what is the purpose of this API? In documentation it is mentioned like to disable UI associated with it.

Jan Šlegr said:

In such case the problem is probably in not synchronized state (internal state is different than "command presentation" in ribbon).

If not, can you let me know how to achieve it

Rajesh Varatharajan said:

We are not doing anything with ribbon. Just we are trying programmatically to disable button.

Sorry, I do not understand, there is conflict in your statement: You do nothing with ribbon, but want to disable the button? It means you want to change the ribbon.

Or you mean that you do nothing with ribbon in your code? I do not ask for such information.

Rajesh Varatharajan said:

SetIsEnabled - what is the purpose of this API?

I guess the method description is clear.

Rajesh Varatharajan said:

If not, can you let me know how to achieve it

Sorry, but when you do not bother to answer my question what happens when you rebuild the ribbon (e.g. explicitly manually) after the command is set to be disabled, how can I help you? Do you expect I will spend my free time to build test code and try its behavior instead of you?

I do not know whether my understanding of XCommand is correct, but as described in documentation, there is a synchronization mechanism implemented in MVVM pattern. It allows to evaluate commands states and update GUI when necessary (when a specific synchronization event is created).

But there is no information available, whether changing e.g. enable state also automatically fires the synchronization event. I think it does not, because when more command features is set and every such change will fire new synchronization, it will be probably quite expensive process.

To rebuild ribbon is simple test, because during this process, all displayed commands are re-evaluated. So when the command representation in the ribbon (icon) will be still enabled, I guess the problem is in the code. When it will be disabled, the problem is that you have to request the tool refresh.

Without knowing the test result, I think there is no reason to invest time to try to find another solution (when it's not clear why existing does not work as expected).

With regards,

  Jan

I may be wrong, but I think there is a misunderstanding of the relation / dependency between XCommand and ribbon and also what XCommand is.

XCommand is used to define command (let's imagine it as "named specification of some action").  It represents complex definition (every command has many features) and also related functionality. But, XCommand has no explicit relation to ribbon. XCommand is integral part platform engine, whereas the ribbon is "only" a representation of selected functionality to a user.

When ribbon is defined to show some command, it checks its parameters (e.g. what icon and label should be used) and also state (whether it's hidden, enabled, selected...). After this process is finished and the command is rendered, the ribbon waits to be notified whether the process should be repeated again (because something changed).

Regards,

  Jan

Hi Jan Šlegr,

Thanks for your input and your answer is correct(problem is probably in not synchronized state),we are facing this problem. So, resolve this issue how to rebuild/refresh the ribbon to replicate the passed code state(SetIsEnabled(FALSE);).

Please suggest your views to solve.

Thanks,

Arul K

Hi Arul,

Arul Kulandaivel said:

Thanks for your input and your answer is correct(problem is probably in not synchronized state)

thanks for the response and the confirmation (I do not know why Rajesh Varatharajan did not do it).

Arul Kulandaivel said:

So, resolve this issue how to rebuild/refresh the ribbon to replicate the passed code state(SetIsEnabled(FALSE);).

To rebuild the ribbon is wrong idea, because it's expensive slow operation (all definitions from rsc and dgnlib files are read again). It's clearly visible when the ribbon is rebuilt using key-in, there is a substantial delay. To rebuild ribbon from scratch is good tool for testing, but too slow for production code.

In my opinion the simplest option is to send proper synchronization message, so the command is reevaluated. But I am not sure what message is the best one. You can check what UI sync events are associated to this command and just to select what seems to be the most general one.

Alternatively, but I do not check whether such API exists, is to ask the UI object to refresh.

With regards,

  Jan

Arul Kulandaivel said:

how to rebuild/refresh the ribbon to replicate the passed code state(SetIsEnabled(FALSE);).

The recommended way to customise MicroStation's ribbon UI is via Named Expressions.  Use a Named Expression to Display or Hide a UI widget.

In other words, your solution may involve no programming: you should be able to accomplish dynamic ribbon control through MicroStation's built-in tools.

You might like to visit the Administration Forum to find answers to questions about customising the ribbon.

Jon Summers said:

In other words, your solution may involve no programming: you should be able to accomplish dynamic ribbon control through MicroStation's built-in tools.

In my opinion it's not correct, because it cannot be used when MicroStation command should be disabled (like, in the discussed case, Open View attributes dialog icon.

Regards,

  Jan

Jan Šlegr said:

it cannot be used when MicroStation command should be disabled

The question is 'How do I disable a menu?', not 'How do I disable a MicroStation command?'

If the OP really wants to disable a MicroStation command, then he should ignore XCommands and instead monitor MicroStation's input queue.  An input queue monitor enables one to reject a command, whatever its origin.

Jan Šlegr said:

I think there is a misunderstanding of the relation / dependency between XCommand and ribbon and also what XCommand is

You're correct: perhaps the OP could clarify his real requirement?

Jan Šlegr said:

it cannot be used when MicroStation command should be disabled

The question is 'How do I disable a menu?', not 'How do I disable a MicroStation command?'

If the OP really wants to disable a MicroStation command, then he should ignore XCommands and instead monitor MicroStation's input queue.  An input queue monitor enables one to reject a command, whatever its origin.

Jan Šlegr said:

I think there is a misunderstanding of the relation / dependency between XCommand and ribbon and also what XCommand is

You're correct: perhaps the OP could clarify his real requirement?