After using comment hotkey to incapsulate an activity and moving out of context, other hotkeys start to fail. Core UI WYSIWYG principles aren’t respected and my trust in the interface is damaged.
Steps to reproduce:
Open a new blank project
Create a new sequence in main
Add log message (or anything else) activity to message
Use ctrl+d to comment out activity
Select outer sequence
Select the log message activity
Attempt to uncomment with ctrl+e, notice this fails
Attempt to save with ctrl+s, notice this fails too. This is really bad.
Tried the steps you mentioned. Works fine for me. May be you can share workflow. That might have some corrupted data or any multiple references to namespace.
edit: i got the issue. you mentioned you tried uncommenting the log message by sending ctrl +e to the log message activity.
That doesn’t work that way.
The Ctrl + E command is used to remove the selected comment activity that means it works only on the “comment out” activity window
To disable an activity, you select that activity and press ctrl+D.
But to enable it back, you need to select the part where it says “Comment out” and then press ctrl+E, then it works and enables activity back.
It wont work if you try to enable it by selecting disabled activity or its immediate sequence that gets created(named “Ignored activities”) when you disable it.
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.
It’s not supposed to do anything. You’re forgetting that there could be multiple activities disabled, all inside the one sequence. You enable by selecting the outermost “// Comment” sequence.
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.
So saying
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.
My test:
Sequence
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.
@jeevith you are right, there is a bug on our side. We already have it in the backlog but the fix is not trivial. Thanks for your patience and we will bring a fix in a future release.
prashant1603765
ashokkarale
imad-pro
Matias_Clemente.Arg
Shah_Rukh