Topics

JTAlert name


Michael Black
 

Laurie...I have a task mangement program that I'm close to releasing.

But if multiple JTAlert processes are started it can't tell the difference between them.

Would it be possible to add a /name=XXX option so each instance could have a unique name -- that way I can associate the task entry with a specific JTAlert window.

Unless you know of some other way to associate one JTAlert to a specific instance.

Mike W9MDB



HamApps Support (VK3AMA)
 

On 21/11/2020 4:59 pm, Michael Black via groups.io wrote:
But if multiple JTAlert processes are started it can't tell the difference between them.

Would it be possible to add a /name=XXX option so each instance could have a unique name -- that way I can associate the task entry with a specific JTAlert window.

Unless you know of some other way to associate one JTAlert to a specific instance.

Mike W9MDB

Mike,

You can already do that. By design JTAlert ignores any unsupported command-line options.

However, that will not always be the case and should not be relied upon as a long term solution. Not all applications are so forgiving and will error when an unrecognized parameter is passed in the command-line. IMO, you should avoid relying on such a technique to identify specific instances of applications you need to manage.

IMO, a better technique is for your program to maintain an internal list of the OS assigned PID for each of the started applications and use that PID for managing the different instances. Likely your already capturing the PID when each application is started.

The "/name=xxx" technique will only work with the main JTAlert.exe executable. It is not passed to the processes started by JTAlert.exe like JTAlertV2.Manager.exe and JTAlertV2.Decodes.exe.

de Laurie VK3AMA




Michael Black
 

But I want the distinction to last over a restart of my app too...and the PID won't do that.
The PID isn't a guaranteed association to any specific named instance 
Only thing I have to work with is Window names which I'm not particular fond of relying on that as it's app-specific.

Mike




On Saturday, November 21, 2020, 12:56:10 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 21/11/2020 4:59 pm, Michael Black via groups.io wrote:
But if multiple JTAlert processes are started it can't tell the difference between them.

Would it be possible to add a /name=XXX option so each instance could have a unique name -- that way I can associate the task entry with a specific JTAlert window.

Unless you know of some other way to associate one JTAlert to a specific instance.

Mike W9MDB

Mike,


You can already do that. By design JTAlert ignores any unsupported command-line options.

However, that will not always be the case and should not be relied upon as a long term solution. Not all applications are so forgiving and will error when an unrecognized parameter is passed in the command-line. IMO, you should avoid relying on such a technique to identify specific instances of applications you need to manage.

IMO, a better technique is for your program to maintain an internal list of the OS assigned PID for each of the started applications and use that PID for managing the different instances. Likely your already capturing the PID when each application is started.

The "/name=xxx" technique will only work with the main JTAlert.exe executable. It is not passed to the processes started by JTAlert.exe like JTAlertV2.Manager.exe and JTAlertV2.Decodes.exe.

de Laurie VK3AMA




HamApps Support (VK3AMA)
 

On 22/11/2020 5:59 am, Michael Black via groups.io wrote:
But I want the distinction to last over a restart of my app too...and the PID won't do that.
The PID isn't a guaranteed association to any specific named instance
Only thing I have to work with is Window names which I'm not particular fond of relying on that as it's app-specific.

Mike
Why not just enumerate the already running processes when you program starts to get the current PIDs (and the process names, main window Hwnd, command-line, etc) for the applications your interested in managing.

Relying on a unique name passed in the command-line for an application instance will be problematic. While it will work with the current JTAlert, many other applications will not support some arbitrarily assigned command-line parameter and will error if an unsupported param is detected.

If your program is generic in nature designed to manage the startup/closing of arbitrary user-defined applications you need to avoid application specific hacks like a "/name=xxx" param.

If you need to track previously started applications across your program restarts you would need to persist some data like a PID that was assigned when your first started that application.

You have everything you need to uniquely identify running applications through the process name, its command-line, window hwnd and PID.

Relying on the command-line only is insufficient, you need to record the State of any application you start so that you can locate it again when your program is restarted. What you include in the State object will likely need to be the PID, Main window Hwnd and command-line if you want to ensure the uniqueness of the running process.


de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 22/11/2020 5:59 am, Michael Black via groups.io wrote:
But I want the distinction to last over a restart of my app too...and the PID won't do that.
The PID isn't a guaranteed association to any specific named instance 
Only thing I have to work with is Window names which I'm not particular fond of relying on that as it's app-specific.

Mike
Did you try the /name=XXX command-line parameter?

From Process explorer...


de Laurie VK3AMA


Michael Black
 

Yes...that work's...but you said it won't work in the future.

Mike




On Saturday, November 21, 2020, 02:38:49 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 22/11/2020 5:59 am, Michael Black via groups.io wrote:
But I want the distinction to last over a restart of my app too...and the PID won't do that.
The PID isn't a guaranteed association to any specific named instance 
Only thing I have to work with is Window names which I'm not particular fond of relying on that as it's app-specific.

Mike
Did you try the /name=XXX command-line parameter?

From Process explorer...


de Laurie VK3AMA


Michael Black
 

Trying to make this bullet proof.
Imagine you start multiple JTAlerts -- then start my app.  You don't have sufficient information to tie each to a specific instance.
I do remember the PID...but that's not sufficient if the user restarts something outside the app while the app is down.
Each command-line invocation must be unique and the only way to do that is with the command line arguments which are different for every other app around.

Mike





On Saturday, November 21, 2020, 02:31:49 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 22/11/2020 5:59 am, Michael Black via groups.io wrote:
> But I want the distinction to last over a restart of my app too...and
> the PID won't do that.
> The PID isn't a guaranteed association to any specific named instance
> Only thing I have to work with is Window names which I'm not
> particular fond of relying on that as it's app-specific.
>
> Mike

Why not just enumerate the already running processes when you program
starts to get the current PIDs (and the process names, main window Hwnd,
command-line, etc) for the applications your interested in managing.

Relying on a unique name passed in the command-line for an application
instance will be problematic. While it will work with the current
JTAlert, many other applications will not support some arbitrarily
assigned command-line parameter and will error if an unsupported param
is detected.

If your program is generic in nature designed to manage the
startup/closing of arbitrary user-defined applications you need to avoid
application specific hacks like a "/name=xxx" param.

If you need to track previously started applications across your program
restarts you would need to persist some data like a PID that was
assigned when your first started that application.

You have everything you need to uniquely identify running applications
through the process name, its command-line, window hwnd and PID.

Relying on the command-line only is insufficient, you need to record the
State of any application you start so that you can locate it again when
your program is restarted. What you include in the State object will
likely need to be the PID, Main window Hwnd and command-line if you want
to ensure the uniqueness of the running process.


de Laurie VK3AMA








HamApps Support (VK3AMA)
 

On 22/11/2020 8:22 am, Michael Black via groups.io wrote:
Yes...that work's...but you said it won't work in the future.

Mike
OK,

What I'll do is guarantee support for a dedicated user-defined command-line "id" parameter. eg
"/id=xxx"

While any arbitrarily named parameter is currently supported that is undocumented and not guaranteed for future releases, especially as the code base moves over to new .NET technology. I will guarantee support for a "/id=xxx" parameter in all future versions.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 23/11/2020 6:13 am, HamApps Support (VK3AMA) via groups.io wrote:
On 22/11/2020 8:22 am, Michael Black via groups.io wrote:
Yes...that work's...but you said it won't work in the future.

Mike
OK,

What I'll do is guarantee support for a dedicated user-defined command-line "id" parameter. eg
"/id=xxx"

While any arbitrarily named parameter is currently supported that is undocumented and not guaranteed for future releases, especially as the code base moves over to new .NET technology. I will guarantee support for a "/id=xxx" parameter in all future versions.

de Laurie VK3AMA

In addition, if an "/id" parameter is defined, it's value will be displayed in the JTAlert title-bar status area. That will be available with the next public release.

de Laurie VK3AMA


Michael Black
 

Muchos gracias Laurie...

Mike




On Sunday, November 22, 2020, 02:45:14 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 23/11/2020 6:13 am, HamApps Support (VK3AMA) via groups.io wrote:
On 22/11/2020 8:22 am, Michael Black via groups.io wrote:
Yes...that work's...but you said it won't work in the future.

Mike
OK,

What I'll do is guarantee support for a dedicated user-defined command-line "id" parameter. eg
"/id=xxx"

While any arbitrarily named parameter is currently supported that is undocumented and not guaranteed for future releases, especially as the code base moves over to new .NET technology. I will guarantee support for a "/id=xxx" parameter in all future versions.

de Laurie VK3AMA

In addition, if an "/id" parameter is defined, it's value will be displayed in the JTAlert title-bar status area. That will be available with the next public release.

de Laurie VK3AMA


Laurie, VK3AMA
 

On 23/11/2020 7:48 am, Michael Black via groups.io wrote:
Muchos gracias Laurie...

Mike
Mike,

Minor change in the name, the /id parameter clashes with the same param I am using in some other code. Use /myid instead.

de Laurie VK3AMA