XYplorer Beta Club

I've been experimenting with running a 2nd instance of XY using /ini= command line parameter with something like this below and it works fine, though it brings up the question. Can I feed a new ini into the existing instance XYplorer? I haven't had any luck doing so.The /ini= parameter is really intended to load a XY with a given ini file. I know I can use the other command line switches such as like /hwnd=<hwnd> and /flg=2, but these really exist to enable the user to feed a "script" in to the existing instance of XY. I've used them in a number of scripts. However, what if I want to simply, and hopefully seamlessly, change the XYplorer.ini file to another modified ini file without starting a new instance? I could really see some value in being able to do so. It would be like changing XY's entire configuration (or at least most of it) on the fly. It might be a nice feature to be able to immediately and directly load a different ini file, like an "SC iniload XYmodified.ini" scripting command. Thanks.

I seemed to have missed the fact that XY does have a "Load Configuration..." under File | Setting Special where you can load an "ini" (CID #181), but that opens a "Open file" (ini) dialog box. It might be nice to be able to accomplish that via a script directly as I mentioned, without a dialog box with a SC iniload "my_own.ini". I'm sure it wouldn't be as seamless as I hoped since basically it's like a restart, but there would be some value in it in any case. Thanks.

Hi klownboy (Ken)
the way I got round this was to use zipfiles for different Xyplorer.ini's.
then using this can be seen in use with my tagchanger
http://www.xyplorer.com/xyfc/viewtopic. ... 6&start=90
also in Kataloger http://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=15193

Hope this helps

Hi totally mad one, that's a great idea. I suppose you could also use SC copyas/rename to overwrite XYplorer.ini with other named ini files. Though in some ways, it is nice to deal with ini files that have specific names and you can't do that with a general restart. An ini with a different name helps to keep you aware what ini file with which you are dealing and the purpose of that particular ini file. When you enter Configuration, the top header will tell you the name of the name of the particular ini file and therefore you know the changes you make will only affect that particular ini. You can even have the ini file name displayed in XY's header. I suppose it all depends on what you're trying to accomplish, but I still think there's some benefit in being able to directly load a specific ini file in scripting.

For the purpose that I'm fiddling around with at the moment, I'm probably better off doing what I'm doing in a second instance of XY. So in this case, I can use a specifically named ini file. Thanks for the idea TM1.

Didn't read this all in detail, but just a thought: couldn't you, instead of loading some ini into the current XY, start a new XY with the wanted ini, and terminate the current?

PeterH wrote: ...couldn't you, instead of loading some ini into the current XY, start a new XY with the wanted ini, and terminate the current?

Hi Peter, sure that's another possibility. As in the first post, I start the new instance of XYplorer with a /ini=modified.ini, but you could go one step further I suppose and terminate the original one. Quite a while ago, I setup a keyboard shortcut to terminate the second instance using: if(get("instance") == "2") {exit n}, but I'm not sure how I'd "automatically" in scripting terminate the original (1st) instance. The second instance comes up and becomes the active instance of XY. Is there a way within XY scripting to single out the original instance to close it without making in active? The SC exit modes only work on the active instance. In most of the situations I have, I want the original instance to stay open anyway. My original post question was written more because I a bit surprised that there isn't a "iniload" type SC without going through a load file dialog box. Thanks.

Hm - somehow we seem to see the situation in a different way

After loading another ini into the current XY you would have the one XY active, with the new ini

If, from a script,
- you start a new XY with a different ini,
- then exit the current XY
you have the same, I think

The first one executes the script to load a second one with a new ini file? So where is the problem that you kill the first instance at the end of the script?

Yeah, you're right. I just tried it. SC "exit n" in the script, since it is run from the original instance will close that instance and not the newly opened instance. I was wrongly assuming the "exit" might work on the active or newly opened instance and not the original and forgetting it will work on the instance which ran the script. Duh. Thanks guys.

So that's what you said about instances

HI, as a follow-up to this topic, I was wondering if someone knows of a way to determine if there are 2 instances of XYplorer open. I know I can determine if the active one (on top) is instance "1" or instance "2" using get ("instance"), but is there a way using XY scripting (i.e., w/o resorting to external means like AHK) to tell if there are 2 instances running so I can take the appropriate action based on that. I was thinking I could establish a perm variable (e.g., $p_instance=2) when I initially open a 2nd instance, but might there be some other way of detecting if there are already 2 instances running?

runret(), tasklist (fi with imagename eq xyplorer.exe), gettoken() with count?

Thanks highend, that made me think of the function "isprocessrunning" though that was to determine if a single process was running. I'll take a look at using tasklist. Thanks.

I got this to work to determine if more than one instance of XYplorer are running (regardless of which instance is active):However, after just shy of a million attempts, I haven't been able to do it without using HEREDOC. Yeah, it's the quoting.

For what would you need a heredoc?
Be careful how you handle your runret command...

E.g. Will show two instances (because of the text...)...