Allow only one instance of `XTB` in memory

[shytikov]

It's related to #574.

It would be nice to have a setting that controls how many instances of XTB could be present in the same time. I believe having one instance should be suitable for most users and their scenarios (if they have another needs, setting could be switched off).

But having only once instance makes sense, since right now we have only one plugins location shared between all copies of XTB, so changes made by one instance could cause issues in another, for example, uninstallation of plugin, or update of it, one of instances will get Access Denied exception.

In addition, users' experience will be far more predictable if we can actually say which instance will respond on protocol calls (it would be single instance, actually, so no confusion)

[rappen]

Being the negative backwards guy I can be... ...why?

Everything (almost) else on your pc can be run in several instances, and yes when I double click a json file I don't know which instance of Visual Studio that will actually open the file, but we learn to live with it... VS shares all extensions etc and yet I feel the need to run several instances at the same time. I also like being able to run several instances of XTB when working against different environments and don't think it is enough with just multiple tabs.

This "feature" feels like something that would just make the toolbox more complex and add more code to maintain.

Best regards,

mrnegativity #mrkeepitsimple

[shytikov]

I think we need to have an option: either run as many instances as we want, or combine all calls to one instance.

I mentioned my motivation — manipulation with plugins, sometimes plugins are blocked by one instance, and we try to manipulate it from another.

Idea with shortcuts to plugins, if they are share same connection what's the point to open additional instances of XTB?

Protocol feature — or maybe scripting XTB from outside, it should be predictable which instance will execute commands.

I believe XTB will become more usable if users will be able to decide which scenario they feel more comfortable with.

[MscrmTools]

I love all your feature requests, I do... But I feel not enough skilled nor I can find time to implement them... As @rappen discovered lately, I'm just working on XTB on my spare time, I'm not sponsored by my employer to develop XTB so when big improvements are requested, this is a mountain to climb for me

[rappen]

Feature bloating is the beginning of the end of every IT system. Excessive configurability too... Letting users decide what they are not capable of deciding leads to unnecessary support issues.

-RappWisdom

[shytikov]

@MscrmTools same here, I willing implement that on my spare time, the problem is that I need to know does anyone else feels that they need that feature. I would feel bad if I implement something that other wise people will not like :)

[rajyraman]

I was thinking about the same single instance feature yesterday. When I googled this on how it can be implemented, I saw a post with Mutex. Thats when I stopped looking into this further.

[rappen]

My strong suggestion is that this is not implemented at all. Users should be able to handle XTB the same way they have to handle most other applications on their PC.

Regarding #574 this should IMHO just look for running XTB processes and either grab the first available or the last used (if possible to determine), or start a new XTB process if none is available. The only possibly nice setting I see at this point is to be able to tell #574 to always open protocol links in a new instance of XTB.

Case closed? ;)

[shytikov]

@rajyraman, what do you think?

I came up with this suggestion after seeing your proposals regarding protocol (#574).

[daryllabar]

Your link @shytikov is for resolution. Did you grab the wrong one?

[shytikov]

@daryllabar you're right, corrected by comment above.

[rajyraman]

Single instance would be useful if shortcuts & custom protocol handler are implemented. I have to google this further. This is what I am trying to achieve:

1. Open a shortcut when XrmToolBox already open. Context is switched to XrmToolBox and the correct tool and/or connection is selected.
2. Click a link with a custom protocol handler on a webpage. Same behaviour as 1

Are people currently using different XrmToolBox instances simultaneously with different connections? In that case, single instance might be a problem.

[daryllabar]

So is this request just so if #574 is implemented, the user won't have to guess what XrmToolBox the link will have opened up in, because there will only be one?

[maturmel]

Just my two cents, I am getting up to speed with the latest XrmToolBox (2017) as I have been using the tool for a while and got stuck a few years on 2015.9 version. I am surprised to see the plugins folder being moved to a central and shared location.

I had been using two copies of the XrmToolbox folder (exe & everything, and plugins subfolder) to use one for developing my custom plugins, while the other executes work on production environment. I have made a substantial library of internal tools at my work to be used by the IT/DEV team on our CRM production instance for various support scenarios.

Now it seems with the new way plugins are stored I won't be able to work my dev quietly while not disturbing whatever's running in prod. For example I have plugins that use the platform to initialize new CRM custom fields based on our internal logic, as you all know I can't just set a value thru SQL so I have been using XrmToolBox to do that hefty work. Our CRM db has millions of records to update in such scenarios so often this isn't accomplished in a matter of minutes nor even hours or days. As a result I run XTB on my workstation pretty much 24/7.

I'm trying to evaluate how I can work around that new plugin store "limitation" as I would very much like to move to the most recent version of XTB and update all my plugins code to be on par with it, but as the same time I need to be able to have two separate environments, ideally from my workstation.

Hope I did not wake up a post that was archived too old but I thought my scenario was some sort of a segway from the main discussion in this thread

[MscrmTools]

Hi, no problem. You can still have dedicated storage location for different instances of XrmToolBox. You just have to run the instance from a shortcut and add the argument /overridepath:your_path

This way, all the storage folder structure is recreated in your_path (plugins, settings, connections, etc)

[maturmel]

Hi, Thanks for the reply! That's great, sorry I must've missed that part in the update notes. I will use the override path switch for my dev folder, that's perfect.

Regards