Date   

locked Re: NE9U not highilghted as wanted callsign

HamApps Support (VK3AMA)
 

On 22/11/2020 1:16 pm, Jim Reisert AD1C wrote:
I don't see any way
to select worked B4 bands.
You can't select Worked B4 bands, all bands are considered. A band that is considered worked B4 is determined from examining your Log.

Since I have some concrete examples of Callsigns failing for you, the next step is for me to try reproduce the problem using a setup similar to yours. Please use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis. In a separate email send me a copy of your log file (send to vk3ama.ham.apps [at] gmail.com)

de Laurie VK3AMA



locked Re: NE9U not highilghted as wanted callsign

Jim Reisert AD1C
 

Unchecking the "Ignore grid square" box made no difference.

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us


locked Re: NE9U not highilghted as wanted callsign

Jim Reisert AD1C
 

The call I added was WB0CPW. Just transmitted again. Still cyan.
Other calls on the same band in the same sequence turned purple.

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us


locked Re: NE9U not highilghted as wanted callsign

Jim Reisert AD1C
 

I just added another call, WB0-something. Never worked before, ever.
Originally Cyan background. Did not turn purple on his next
transmission.

I added the call, then got interrupted with my previous E-mail reply,
so forget what it was.

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us


locked Re: NE9U not highilghted as wanted callsign

Jim Reisert AD1C
 

What Band/Mode/Grid options do you have set for the "Worked B4" Alert?
I have "Ignore Gridsquare" checked, nothing else. I don't see any way
to select worked B4 bands.

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us


locked Re: NE9U not highilghted as wanted callsign

HamApps Support (VK3AMA)
 

On 22/11/2020 12:52 pm, Jim Reisert AD1C wrote:
I assume if the call is on a different
band it won't be considered "worked before" and will display
highlighted.

What Band/Mode/Grid options do you have set for the "Worked B4" Alert?

de Laurie VK3AMA




locked Re: NE9U not highilghted as wanted callsign

Jim Reisert AD1C
 

"Alert when decoded Callsign worked B4" is checked. In general, I
probably want that unchecked. I assume if the call is on a different
band it won't be considered "worked before" and will display
highlighted.

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us


locked Re: NE9U not highilghted as wanted callsign

Jim Reisert AD1C
 

On Sat, Nov 21, 2020 at 6:39 PM HamApps Support (VK3AMA) via groups.io <vk3ama.ham.apps=gmail.com@groups.io> wrote:

Does NE9U already exist in your log for those 2 bands? If so he wont be alerted unless your enable the "Alert when decoded Callsign worked B4" setting for the Wanted Callsign Alert.

No, I have only worked him on 30m FT8, but the spots were on 17m and 15m.  They did not highlight.

I just added K2HT.  He's calling CQ on 80m.  I have a 15m QSO.  The new call is being highlighted correctly.

I wish I could figure out the pattern!

I wishI wish I could figure out the pattern..._.__,

--
Jim Reisert AD1C, <jjreisert@...>, https://www.ad1c.us


locked Re: Color in the box

HamApps Support (VK3AMA)
 

On 22/11/2020 9:20 am, Neil Foster wrote:
I know I asked about this before but it appears I have not done something correctly.
In JT Alert when a South American station appears the box in JT Alert has a yellow background. While not a problem how do I get the tint gone?. Either I am dense
at age 86 or I am not doing something correctly.
Thanks
Neil   N4FN
If a callsign is getting its background colored than it is because that Callsign is generating an Alert. If you don't want the coloring then you will need to turn off that Alert type. Or alternatively you can change the color for that Alert to something more suitable.

You can get a quick overview of all the Alert color combinations you have set by opening the "Alert Types Summary Window" via the view menu.

de Laurie VK3AMA


locked Re: NE9U not highilghted as wanted callsign

HamApps Support (VK3AMA)
 

On 22/11/2020 11:55 am, Jim Reisert AD1C wrote:
For some reason, the call NE9U is not being highlighted as a wanted
callsign.  It's in the list.  Other calls are being highlighted.  I
saw the same problem on both 17m and 15m.  I tried removing it and
adding it again, nothing changed.  Very strange.

- Jim
Does NE9U already exist in your log for those 2 bands? If so he wont be alerted unless your enable the "Alert when decoded Callsign worked B4" setting for the Wanted Callsign Alert.

de Laurie VK3AMA


locked Re: NE9U not highilghted as wanted callsign

Jim Reisert AD1C
 

Another call I added isn't working either (KB0QEF). I am seeing other
callsigns highlighted in the same receive sequence. Is there a limit
as to the maximum number of wanted callsigns supported by the program?
I'm running JTAlert 2.16.16

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us


locked NE9U not highilghted as wanted callsign

Jim Reisert AD1C
 

For some reason, the call NE9U is not being highlighted as a wanted
callsign. It's in the list. Other calls are being highlighted. I
saw the same problem on both 17m and 15m. I tried removing it and
adding it again, nothing changed. Very strange.

- Jim

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us


locked Re: Color in the box

Randall Tudor
 

At 86 that is OK. You deserve it.

Randy
K4ODL 


On Nov 21, 2020, at 5:20 PM, Neil Foster <archernf@...> wrote:

I know I asked about this before but it appears I have not done something correctly.
In JT Alert when a South American station appears the box in JT Alert has a yellow background. While not a problem how do I get the tint gone?. Either I am dense
at age 86 or I am not doing something correctly.
Thanks
Neil   N4FN


locked Color in the box

Neil Foster
 

I know I asked about this before but it appears I have not done something correctly.
In JT Alert when a South American station appears the box in JT Alert has a yellow background. While not a problem how do I get the tint gone?. Either I am dense
at age 86 or I am not doing something correctly.
Thanks
Neil   N4FN


locked Re: JTAlert name

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








locked Re: JTAlert name

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


locked Re: JTAlert name

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


locked Re: JTAlert name

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


locked Re: JTAlert name

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




locked Re: JTAlert name

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



3201 - 3220 of 35446