Date   

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




locked Re: Idea for Text Message Users

Guy G4DWV 4X1LT
 

If I want more than a basic QSO, I do not use any JT/FT modes. Simples!
--
73 de Guy G4DWV 4X1LT


locked 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



locked Re: Idea for Text Message Users

WB8ASI Herb
 

Thanks so much Laurie.  Having fun this evening using the Decodes Window underlining for text to quickly say thanks for the QSO, and tossing in any other comment if we make a connection.  Makes a good connection beyond just the basic QSO.   My friend often asks me if I'm on my FAX machine rather than on my radio. LOL


locked Re: New Feature Enable Fill In Circle for On Line Text Messages?

Laurie, VK3AMA
 



On 20/11/2020 9:53 pm, Hasan Schiers N0AN wrote:
I usually don't have enough monitor real estate to have that window open. Will play with it.
73, N0AN
Hasan

FYI, you can restrict which columns are displayed in the Decodes window, right down to a single "Callsigns" column if desired.

de Laurie VK3AMA


locked Re: LOTW data is often wrong

Laurie, VK3AMA
 

On 18/11/2020 4:17 am, Torsten - DL9GTB wrote:
unfortunately for a long time I have had to find out again and again that the LOTW data is often incorrect or not up-to-date. How can I improve this?

73 de Torsten - DL9GTB
Torsetn,

Do you still what me to look into this for you? If so, I will need an example Callsign (one is enough) that is being reported incorrectly from JTAlert. I can't do any investigation without a problem callsign to examine and trace through the different source files and the scripts used to generate the Callsigns database.

de Laurie VK3AMA


locked Re: ADIF file will not ..

HamApps Support (VK3AMA)
 

On 21/11/2020 11:00 am, Rick Wyrwas wrote:
Jtalert loads a arid file but I can’t find at time this file or when I do won’t load to LOTW. Driving me nuts

The JTAlert Settings, "Logging -> Standard ADIF File" section, shows you where the ADIF file is located. You can use the Select button which opens a selection dialog from which you can copy the File location from the top navigation area.

eg.



de Laurie VK3AMA



locked Re: RR73 73 PROBLEM

HamApps Support (VK3AMA)
 

On 20/11/2020 8:31 am, tonypedro wrote:
dear colleague, please tell me how this alert is turned off. thanks qrv atte LU1wh



The Release notes for the new JTAlert version has the answer...
    - WSJT-X Decode Highlighting: "73" or "RR73" decode highlighting no longer
       require the CQ Alert to be enabled. A dedicated setting is now available.
       See the "Applications -> WSJT-X / JTDX" section of the Settings window.
       Note: This and other color highlighting is not available for JTDX.

de Laurie VK3AMA


locked Re: Unexpected announcement

HamApps Support (VK3AMA)
 

On 21/11/2020 5:39 am, John Holmes W9ILY wrote:
I was quite surprised and pleased when I heard an audio announcement for a new state for my WAS. When I looked at the JTAlert decode listing, it was full of calls as the band was very busy and my "new state" callsign was actually below those that were displayed on the four decode lines and was off the screen. I think it is great that the audio announcement data reads all of the decodes, not just the ones that are displayed. Everything appears in the decodes window, of course. This is another reason to keep the decodes window open.Thanks, Laurie.
73,
John W9ILY
Good stuff.

BTW, you can have the main JTAlert window set to no display lines and decodes will continue to be displayed in the Decodes Window and Alerts will still be generated. That is how I run JTAlert here.

de Laurie VK3AMA

5541 - 5560 of 37778