mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
Joined: Sep 2015
Posts: 101
klez Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Sep 2015
Posts: 101
Hi again!

I have a suggestion to include in mirc an option to use multiple instances of mIRC or only one (for example if somebody has the mirc open and start it again, the mirc will activate main window and not start another process if the option to allow multiple instances are deactivated)

Joined: Nov 2009
Posts: 295
P
Fjord artisan
Offline
Fjord artisan
P
Joined: Nov 2009
Posts: 295
You can actually do this with a script, it's not quite as clean or foolproof as if the program would do it but it works. Still an option for this might be nice. I know other programs have similar options.

Code:
on *:start:{ if ($script(1) != $script) { .reload -rs1 $script } | if ($numMirc > 1) exit }

alias numMirc {
  .comopen numMirc1 WbemScripting.SWbemLocator
  if ($com(numMirc1)) .comclose numMirc1 $com(numMirc1,ConnectServer,3,dispatch* numMirc2)
  if ($com(numMirc2)) .comclose numMirc2 $com(numMirc2,ExecQuery,3,bstr, $& 
    SELECT * FROM Win32_Process WHERE ExecutablePath = $qt($replace($mircexe,\,\\)) $&
    ,dispatch* numMirc3)
  if ($com(numMirc3)) {
    var %total $comval(numMirc3,0)
    .comclose numMirc3
    return %total
  }

  :error
  if ($com(numMirc1)) .comclose numMirc1
  if ($com(numMirc2)) .comclose numMirc2
  if ($com(numMirc3)) .comclose numMirc3
  return -1
}



http://scripting.pball.win
My personal site with some scripts I've released.
Joined: Feb 2011
Posts: 448
K
Pan-dimensional mouse
Offline
Pan-dimensional mouse
K
Joined: Feb 2011
Posts: 448
I set my mIRC to require a password when I start it just so I don't start the same copy of mIRC (and to keep others from running it if I forget to log out of Windows).

Tools -> Options -> Other -> Lock

Added benefit is you can CTRL+MINIMIZE and it will require the password to restore mIRC.

Joined: Dec 2008
Posts: 1,515
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2008
Posts: 1,515
Actually this feature has been requested and in the past.

I agree with this idea, and adding an identifier to reply how many instances are opened, like ($mircuse).

Older post: https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/231335


Need Online mIRC help or an mIRC Scripting Freelancer? -> https://irc.chathub.org <-
Joined: Sep 2015
Posts: 101
klez Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Sep 2015
Posts: 101
i can say is stupid to set a password because to not run multiple process and so on..

is better to place an option of this kind than to make scripts or other ways..

I don't think that is so difficult to make just a simple option, is required Khaled to accept it smile

Last edited by klez; 06/12/15 04:51 PM.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I will add that Windows 10 kind of makes the need for this functionality moot-- at least if you are using the "pin to taskbar" feature.

If you just pin mIRC to the taskbar and disable the minimize to tray functionality, you can ensure that clicking the taskbar button will only ever load a single instance of mIRC (and activate it if it is already running).


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Sep 2015
Posts: 101
klez Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Sep 2015
Posts: 101
Yes, i can put an auxiliary program to not allow multiple instances, im a scripter also and i can make a script as this mentioned above.. but i suggest to introduce this options not only for me, but also for others.
Also, my scripts are not simples, and if a second instance opens, than appears a confirmation dialog due to variables.. yes i can make the mirc through a script to not allow this, but, as i say, is simple to introduce such a option than to apply alternative ways to do it..

Last edited by klez; 07/12/15 06:28 AM.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: klez
is simple to introduce such a option than to apply alternative ways to do it..


I guess I just don't believe this is true. It seems much simpler to say "pin mIRC to the taskbar like you can with every other program" than to try to help a user find this setting in the plethora of mIRC's existing window management options.

It's one thing to add yet another setting to mIRC-- seemingly easy to implement, maybe. But adding yet another setting to mIRC does not automatically mean users will know it exists or where to find it. The difference now is that one of these explanations involves a one-off solution that only works with mIRC, and the other works OS-wide, and is invariably the recommended path forward from Microsoft's perspective. If you have to choose between giving a one-off explanation or one that works for any program, my guess is you would choose the latter.

More importantly, as users start to learn about the taskbar pin functionality in Windows 8/10+, they will eventually stop having this problem in the first place, as they will already know how to manage this issue for all programs. Basically, the multiple instance problem is becoming a legacy issue as Windows introduces new UX paradigms. mIRC gets dinged quite often for being behind on the times when it comes to UX (still using MDI, heavy use of menubars), it seems odd to me to add new features that specifically target problems that are inherently legacy issues. Instead, mIRC should be promoting Windows' new paradigms-- and frankly, that means disabling the default "minimize to tray" behavior-- which would go a long way to solving the multiple instances issue.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2008
Posts: 1,515
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2008
Posts: 1,515
I don't think that a new identifier or an new command related to how many mIRC instances are running is going to be so much trouble if you think that with COMs is 10-15 lines, so adding a new build-in identifier that probably will work using COMs support (like the example above) it will not take days to be coded for sure, also there are some useful (for scripters without COMs experience) features requests about some build-in mIRC identifiers that will help the users for creating codes.


Need Online mIRC help or an mIRC Scripting Freelancer? -> https://irc.chathub.org <-
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Adding an identifier to return the number of mIRC instances running would be useful for scripters-- but that is not what is being asked here.

That said, if the suggestion was just for an identifier, that doesn't sound like a bad idea. In practice, though, it would be more complicated than that-- it's one thing to return the number of processes running, but it doesn't solve the problem of interacting with another process (i.e., activating the 1st process and exiting the 2nd)-- that would require more than just a new identifier, and now things become non-trivial.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2008
Posts: 1,515
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2008
Posts: 1,515
Ok i am focus at the identifier part that you can the other suggested things if you have this identifier included into the mIRC, so the head feature request is to add a new identifier to return how many mIRC instances are currently in use, also in this case it can be added and some properties in case to return more informations like an identifier for catching any progress that is running under the task manager.

Example: $proc(NAME).prop
Properties: .total - .status - .pid - .priority - .cpu - .disk - .network - .cputime - .ram - .desc - .user

Example: $proc($nopath($mircexe)).total

- Thanks!


Need Online mIRC help or an mIRC Scripting Freelancer? -> https://irc.chathub.org <-
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
This only solves half of the problem-- and not very well, either.

$proc($nopath($mircexe)) would not be a reliable way to determine how many mIRC processes are being run-- for one, it would not help if you had multiple mIRC executables with different names (what is the expected behavior there?), and also any other program with mirc.exe as the name would throw off this count. Although unlikely, it's certainly possible that a legitimate process might also have mirc.exe as the executable name, at which point your "single instance" script would refuse to start your chat client.

There are better ways to detect whether mIRC is running than using the task manager. Ideally you would do lookups on mIRC's Window class. $com() is used because it's the only usable methodology without needing access to low-level WinAPI calls.

What you're suggesting might be useful for generalized systems diagnostics, but it's a completely different suggestion from what is being asked in this thread and does not solve the problem at hand (even forgetting the problems described above). You're still not solving the more important half of this problem, which is activating the main mIRC process when the 2nd instance is launched (like Skype does). If you want the above feature, please suggest it separately so as not to hijack this request.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Sep 2015
Posts: 101
klez Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Sep 2015
Posts: 101
Using $coms to determine how many instances of mirc are running take a lot of time for a script to process.. easy way to define that your mirc is really running and how many instances are, it must be called by a win32_process class (Path property), so if as $mircexe == win32_process path than the script will understand how many processes from your mirc dir are running (no matter how many mircs are running on system, this method will look only for mirc.exe process from your mirc dir).
But if I implicate this script, depending of the system, the script will take a time to process all data and is not benefic.
Introducing such a option in mirc to allow/disallow multiple instances and better to include identifiers like $instances etc. will make all things simplest for scripters and for mirc performance.

I don't think that mirc reached his end of life or is not benefic to make more changes, to improve performance and so on. I think mIRC must go on and to introduce more powerful functionality, performance and other things that make the life of mirc easier smile

Last edited by klez; 08/12/15 07:19 AM.
Joined: Dec 2008
Posts: 1,515
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2008
Posts: 1,515
@Argv0: I am trying to improve this feature request and not hijack it by giving some extra opinions, also like your theory in this case there are many ways that this feature can handle.

1. A way to lookup how many mIRC program clients running into the specific machine (with any file name, like: mirc_test.exe or mirc.exe or mirc_anything_here.exe).

2. A way to lookup how many mIRC program clients running into the specific machine via specify the NAME of the program file (like the $proc($nopath($mircexe)).total above).

3. A way to lookup if any mIRC program client is running on startup (like the head suggestion) and activating it instead of opening a new client (that this can be done easy with $proc and not need to be added only this part).

So my opinion of the 3 ways that i gave you is to add an identifier like $prop example and then with this identifier you can do and the other 2 ways that i gave but if you follow any other way of the 3 above then you cannot do the other 2 ways, so at which part my suggestion does not have the correctly point into this feature request?

Examples using $proc:

1)
Code:
ON *:STAT: {
  if ($proc($nopath($mircexe)).total !== 1) { DO_STUFF }
}


2)
Code:
ON *:STAT: {
  if ($instances !== 1) { DO_STUFF }
}
alias instances { return $proc($nopath($mircexe)).total }


- Thanks!


Need Online mIRC help or an mIRC Scripting Freelancer? -> https://irc.chathub.org <-
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
westor, there is overlap between the original request and your suggestion, but 1) you are suggesting something which goes well beyond what is needed for the original feature request, and more importantly 2) the original request asks for something that your suggestion does not provide (specifically the DO_STUFF part of your script, for which the necessary scripting support is missing as well). So, it is effectively a feature suggestion for something different, despite the fact that there is overlap.

Moreover, having mIRC load in its entirety just to have a script activate another mIRC instance and exit itself is going to be seriously, and unnecessarily, slow. In general I'm all for exposing features to scripts, but the originally suggested feature is one of those things that are much better implemented within mIRC itself. Perhaps based on a command line flag.


Saturn, QuakeNet staff
Joined: Dec 2008
Posts: 1,515
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2008
Posts: 1,515
@Sat as i said before i am trying to improve the head feature request by giving more ways (WITH MY OPINION!!) and nothing more, i see that all of you that you don't have something good or similar to say about the head request the only thing you are doing is to complain and nothing more, please respect the other user OPINION and let the head master to decide which way is better to add an feature request, don't yapping the other users comments, also we are talking about the instances and how the mIRC can handle them so i am not reply something that is not related to that stuff.


Need Online mIRC help or an mIRC Scripting Freelancer? -> https://irc.chathub.org <-
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
But that's exactly the thing. So far you have not suggested an alternative. If the "head master" implements your idea rather than klez's original suggestion, then klez's goal will still not have been met. In effect, you are muddying the discussion with your own solution for a different problem, and as such you are hijacking the thread. I am sure that you did not intend to, but that doesn't mean the complaints aren't in the right.

So, in an attempt to turn this around toward something more constructive: how would you then script the DO_STUFF part in your earlier post, such that it does what the original request asked for?


Saturn, QuakeNet staff
Joined: Sep 2015
Posts: 101
klez Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Sep 2015
Posts: 101
westor,

1. Correctly, your idea is good only for make an identifier to tell mirc how many instances are currently running, but you said that this identifier like $proc must collect info by the name of the process and is not correctly. Why? Because someone can make to directories of mirc, one in: C:\mIRC and another in C:\mIRCs and to run them simultaneously. So correctly will be that the identifier will look at this process of mirc where is running from.

2. Second, you didn't understand my suggestion. I mentioned that to introduce an option to allow or disallow multiple instances. If somebody will start mirc and has the option activated to allow only one instance, mirc will never start the second process, but will activate the main window of mirc of this process.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: klez
Why? Because someone can make to directories of mirc, one in: C:\mIRC and another in C:\mIRCs and to run them simultaneously. So correctly will be that the identifier will look at this process of mirc where is running from.


This is where I think things get complicated, and partially why mIRC should stay out of trying to implement this.

It seems to me like your expectation here is that mIRC would allow multiple instances if they come from different copies of the mirc.exe executable in different paths-- but it's unclear that this is how such a feature would be implemented. In other words, you may end up not getting this behavior were it to be implemented. Khaled may decide to check the window class, or a number of other properties, that don't necessarily correlate to the path on disk. Alternatively, if you *did* get this behavior, it may be confusing to other users who expect a single mIRC instance across all exe copies on their system.

If the argument is that each copy of mirc.exe runs a different set of scripts and therefore should be separate instances bound by separate instance checks, you're going to run into even bigger problems, since the same mirc.exe executable can be used to run different scripts (by passing in command line arguments to point to a different mircdir, for example). Does mIRC allow multiple copies of mirc.exe to be run but not the same mirc.exe pointing at separate mircdirs? Does mIRC do a check across all processes to see which $mircdir is being used to determine if it matches the total process count? These questions don't have a "right answer", they can be interpreted in many different ways depending on different usage patterns.

Basically, this road is windy and complicated. I don't think implementing this is as straightforward as you expect it is.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jan 2005
Posts: 192
Vogon poet
Offline
Vogon poet
Joined: Jan 2005
Posts: 192
General reply.

While it would probably benefit some people (or least make it easier for them) if the feature is implemented, as pointed out before it is already possible to use the pin to taskbar feature to achieve the goal already. So adding some option to the mIRC might not be all that important (especially considering that there are just too many different possiblilities exactly how this should be implemented).

As far as "power users" go it is not too difficult to implement this feature via scripting.
Maybe I approach this question wrong but given the set of tools we have right now I feel that we have quite a lot of "power" to implement the "run only one instance" exactly the way each scripter would prefer.
Whether it is to ensure that only one mirc executable runs at any given moment or whether we want to ensure that only one process per mirc.ini is running.

While mIRC is essentially a chat application we still cannot ignore the quite powerful and "FLEXIBLE" scripting engine we are given to work with, so you can extend the program and make it behave exactly the way YOU want it to behave.

---

I faced the situation where I needed to make sure that user wont start two instances of a mIRC bot twice and the road I went was to make sure that user will not be running two instances of mirc that use same mirc.ini.
While there are possibly other ways to reach the same goal my solution was simply utilizing $mircini and communicating between clients via DDE. Which in just few lines of script let me achieve the exact goal.
When I start second instance of the bot it will simply close and bring the already running instance to the foreground.

---

mIRC is a program that can be run simultaneously from multiple directories and that is as far as I can see "by design".
So if you want to have only one instance active then install mIRC to only one directory and utilize pin-to-taskbar feature. Seems like quite simple solution to me.
If you have multiple mIRC executables in various directories then you should already be considered "advanced user" and you are given scripting engine to deal with different scenarios at your own discretion.


echo -a $signature
Page 1 of 2 1 2

Link Copied to Clipboard