The encircled states have some similarities, and after I have completed one, I’d like to keep both of them open in different monitors, so I can easily duplicate some functionality from one to another.
Please avoid any observations such like “you shouldn’t duplicate blah”, “you should arrange this and that in that specific way” and the like, regardless of the rightness of your point. What I’m trying to point out is that it should be specific to undock the contents of these states in diferent tabs, draggable amongst your available screen, and arrange them in whatever disposition you wish.
Instead, you can only open the “Main.xml” once, and only one state can be opened at once, which makes the user interface pretty unfriendly.
I think the limitations are valid, where you can only open a workflow once, it also helps with any sync issues that would no doubt occur should you allow two editable windows of the same workflow to be open at the same time.
If I were in this situation I would copy the workflow, open both and float the screens so they appear side by side.
I disagree the Ui is unfriendly. This is a pretty niche case, and easily overcome in the manner I stated by duplicating the workflow. @Anil_G’s suggestion also works by opening the same project twice, but may lead to something weird if you open the same workflow in two instances of studio at the same time, hence why I would err towards a copy of the workflow as it requires less attention.
Whatever half-decent IDE allows to open several instances (or tabs) of the same file.
Even if it’s a single file, different states of the state machine are “categorized” as different “entities” in the “breadcrumbs” that Studio is using as the pathway to the most “inner” entity. So they could (and, in my opinion, they should, as a way to avoid the situation I’m facing) “decouple” it from that tab and allow to open them in different tabs.
I already resorted to opening the same project in two different instances of UiPath. So you think is this a more reasonable option, opening TWO full IDEs, with the overhead in resource consumption, etc., than, for instance (it doesn’t have to be the only option), merely allowing more than one instance of the same file open at once?
No no, I’m not going to reject the correct ones; only the wrong ones. That’s why I clarified as much as I could what I DIDN’T want. Specially because I already know there are users here who are going to take weird circumvolutions that are of no help.
In fact, THIS (this message I’m writing right know and the explanations I’m giving) is what I was trying to avoid from the beginning.
You didn’t seem to proper understand the question, and thus you’re proposing to try things that seem impossible to do. Thus wasting more time and so.
I propose you try yourself what you proposed. Specially before suggesting to others. So you can realize if it’s possible or not.
For the sake of entertainment, if you wish so, try please to split this General Business Process state machine to “put the code into separate XAMLS”, so you can provide proof of concept that whatever you’re trying to say is possible:
Again, as I already said, whatever half-decent IDE allows to open several instances of the same source code files in their own different tabs. The problem of editing both them at once could be approached in several ways, as other tools already do (there’s a miriad options and different softwares out there):
Let the user to choose if one specific instance is read-only or write only.
Inform the user content has been changed from outside the current “active” instance.
And the like.
Plus you are making assumptions about proposals I didn’t make. Again, you didn’t seem to properly understand the question. The problem I’m complaining against doesn’t have to be sorted out exclusibly by allowing two editable windows of the same workflow.
As the other user, you’re being confused here. I never talked about “workflows”. Read the question; look at the screenshot. I talked about a state machine and these are states. DIFFERENT machine states.
It could be considered a design flaw that different states cannot be edited in different tabs.
In the end, there’s proof in other comments in this thread of what a contradiction is that you consider fair blocking edition of the same file in different tabs in the same Studio instance… but you allow several instances of Studio to be open at once, editing THE SAME PROJECT, extending the potential harm not to a single file but to EVERY FILE IN THE PROJECT and to corruptiong the whole project itself.
What a wildly overly complex solution/view on a simple problem.
Just copy the workflow and view them side by side. Done. Simple. Move On.
I fully agree that opening it in two projects is overkill, I cautioned against it.
Rather than needing to deal with complex sync issues (remember this isn’t a simple text editor), which undoubtedly would have bugs (since we do already have a ‘synced’ workflow with mocks and that IS buggy), just take the simple route.
Seriously, this is as easy as copying the workflow and poof you are done.
Regarding you fussing over the being a state machine, who cares. Its a workflow, you want to look at two different parts of a workflow.
State machines aren’t special, they are just an activity inside a workflow. There is even less point adding special handling to a workflow cause then you’ll complain you cannot look at two parts of a flowchart at the same time.
You are behaving like you don’t want a solution, you’ve been given one, instead you want to ice skate uphill and then blame your skates for not working properly.
This is a feedback forum. I use it for feedback. It’s not the support/help one. I found a weird behaviour, that I consider a bug, and I report it, in case anyone wants to take care about it.
I’m not looking for workaround or alternative ways of solving it, what I already did even before posting. I already stated my point clearly.
It’s not the 1st time in my life I attempt to copy/compare/check different source code areas from the same files. I’ve done it a million times.
I don’t want to copy anything; just compare TWO different elements that appear as TWO different objects: differents states on a state machine.
And by repeating that “who cares about being a state against a workflow” and blah: I insist, I think you didn’t get a full comprehension of what the problem is. Otherwise you wouldn’t be repeating the same over and over again. Workflows, strictly speaking, have different attributes and behaviour than states in a state machine, and behave differently than workflows. Have you used them at all? Maybe I didn’t understand your suggestion, either. I don’t get what you mean by “copy” and “view them side by side”. If you copy, you have to paste it somewhere. I would ask you to ellaborate if it weren’t because I don’t have any interest in losing further time with this topic.
And, again, please avoid any subjective judgement about behaviour, psichology or whatever. That doesn’t belong to the scope of this place. Objectivity and getting things accomplished is my goal. This is a bug report forum. You can avoid all the personal hassle by just adhering to the forum aim, which seem you weren’t aware of, or you’re just criticizing a user for the sake of critizing. If that’s gonna be the behaviour, I’m not interested in further involvement; thanks.
I did say I’d stop engaging with you but I hadnt seen this and want to wrap this up too, so I’ll avoid any new topics from you.
Look, copy the file, view the workflows side by side. Its easy. The effort of copying the workflow temporarily is minimal and not an uncommon thing to do like this.
State machines are not special, I understand them fully. They are an activity that occurs within a workflow. They are in the Microsoft Activty package that form the foundations for the Windows Workflow Foundation that UiPath is built on. A state machine ‘workflow’ is just a workflow with a state machine as the root activity instead of a sequence or flowchart. You can put a state machine in a sequence etc. They do not have different ‘behaviour’ than a workflow, because a workflow is just a container for activities such as state machines, flow charts, sequences in any order you choose.
As such creating special handling for one specific type makes no sense.
Many thanks for bringing this out. I didn’t get what you were meaning and I didn’t think of it.
That said, I still consider that solution rather inelegant and not proper for a tens of thoushands paid software; call it a bug or poor user interface design.
Anil_G
ashokkarale
naveen.s
lrtetala
Yoichi
Youri98
Josh_James
pratik.santani
juan.ramirez1
dheephiga.am