Your test must definitely have some merit. I have noticed this as well but never found what triggered the failure of hotkeys in studio.
I will replicate your test and see if that is the reason we loose hot keys function within studio. I will report back here when done
To others: @kbak here choose both the outer comment and the inner log message in the comment sequence and then uses ctrl+e. So studio should either uncomment or do nothing. It should not disable all hot keys from studio.
This has happened to me in 20.06, 20.08 21.04.03 and 21.04.04 versions of studio.
Studio linked to on-premises orchestrator. Studio running on a Vmvare Horizon VDI.
I never said this (ctrl+e on Commentedout+LogMessage) is the root cause. I said, we need to test the possibility.
Yes, it is a fact that you can lose hotkey functions in UiPath Studio without any failure messages. This is not a hunch, we experience this plenty of times as I mentioned in all the versions we have upgraded. It is annoying and requires restart of Studio when it occurs.
without expierencing it yourself is NOT the the right way. You tested it, it was not the problem great, but that is not enough evidence. There can be many other reasons why this happens.
Again its NOT just about how to correctly use ctrl+E, we all know how it works! What I am saying is there might be a link when ctrl+e is used in certain environments / scenarios as @kbak stated which leads to hotkeys being disabled studio wide.
I am responding to what was described as a failure. It is not a failure that you cannot enable an activity directly, you enable it using the outermost “// Comment” sequence. This is by design. It works exactly the same when you right click. If you right click the activity you do not get the enable option. When you right click the “//Comment” sequence you do get the enable option in the menu.
I understand that after trying to CTRL+E on the wrong activity, you’re saying it can break other keyboard shortcuts.
Again I am not contesting this at all. We know that is how a Commented Out sequence is supposed to be switched on or off. We agree on that.
But lets say you select both the outside layer of Commented Out and also select the items within it just for sake of it / or by mistake and then use ctrl+e. What @kbak meant is that the hotkeys broke after he tried ctrl+e on the selected contents. So there might be some bug which triggers all hotkeys off when this scenario occurs. This has to be tested.
I and my team have just restarted studio until now, but this looked like a possible explanation because it happens more on our Development pipeline where we can have multiple commented out sequences and if we in a hurry selected multiple elements and used ctrl+e, may be that breaks the hotkey (Yes, this part is a hunch as of now and I cannot test it until monday)
I am sorry, but even if the intended usage of the interface is different, there definitely is a failure when the hotkeys are suddenly disabled. Beyond that, there is a WYSIWYG failure in that the expected behavior is not what I get as a user.
I see CTRL+D and CTRL+E as toggles for commenting, even if there is some hidden intended interaction requiring more precision in contextual input. You really shouldn’t blame a user for misreading the interface, a poorly designed interface is a failure of itself.
How is you misreading the interface their fault? The interface makes it very clear that you select the outermost sequence, since that’s the only time the “enable” option is available in the menu.
Yes, if doing it wrong breaks other things they should fix that. But again, you aren’t considering if there are multiple disabled activities, you’re testing with just one. This is why you enable with the outermost sequence.
First off, I use the rightclick menu as little as possible, and try to use hotkeys whenever possible, so there is nothing to misread. I am simply using the interface, and my intention when developing should never be impeded by an opaque interface.
Second, sure, there could be layered disabled activites, but I don’t see why CTRL+E doesn’t just enable the closest activity up the stack? That’s what I would expect. If I am in a disabled context, enable the next layer out. Press the same hotkeys multiple times to completely enable current context.
When debugging, as is mostly the case when I need to switch activities on/off, I usually run embedded activities anyway, and so the context of my work is set by whichever issue I am working on, not by the overall structure of my workflow. Contextual interfaces make our work easier.
You are right to notice this and thanks for the post.
1. Info Log Message
2. Info Log Message
I commented out 2 with ctrl + d
Then clicked and selected 2. (Within commented out block)
Then used ctrl + e
This broke all shortcuts functions
Then I added an annotation to the workflow
All shortcuts returned
Ctrl + e worked on commented out
I tested this scenario and found that if we by mistake choose/select the content of commented out sequence then studio stops all shortcuts.
The weirdest thing is that when you add annotation for the whole file Shift+F2 and write an annotation on the outermost sequence, the Hotkeys/Shorcuts functionality returns!
@loginerror there is a bug in the user interface. Shortcuts should not be deactivated when a user makes a mistake while activating a commented out sequence and definitely not switch on when an annotation is added to the workflow.
There are some overlaps here with respect to shortcuts.
I had this bug since 20.06, 20.08 21.04.03 and 21.04.04 versions of studio and now finally know what triggers this.