Date   

locked Re: 2.5.0 -- AutoIt Error

HamApps Support (VK3AMA)
 

On 21/04/2021 11:25 am, David Merchant - K1DLM wrote:
I'm getting an AutoIT error every time I try to launch JTAlert 2.50.  Specifically, the error says "Line 6817 (File C:\Program Files(x86)\HamApps\JTAlert\JTAlert.exe)  Error: Subscript used on non-accessible variable.

I was able to get it to load initially and was using the software.  However, it wouldn't let me select a station for my next QSO, so I tried restarting it.  That's when the error occured.

Any suggestions?

Thanks & 73,

Dave
K1DLM

Try starting JTAlert without a config file. There may be something in the config that is tripping up JTAlert. See the JTAlert Help file (not the 2.50.0 features help), "Troubleshooting -> Setting Changes Not Remembered" topic. It explains where to find the config file. It may be worth trying to restore an old backup of the config.sqlite file first, explained in that help topic, before proceeding to starting JTAlert without a config file.

If starting JTAlert without a config file corrects the problem, I would greatly appreciate it if you could send me the problem config.sqlite file for examination. send it direct (not via this group) to VK3AMA.Ham.Apps [at] gmail.com

let me know your results.

de Laurie VK3AMA


locked Re: Error Messages on loading New Version 2.50.0 - need Help

HamApps Support (VK3AMA)
 

On 22/04/2021 10:16 am, GLENN - K4ZOT wrote:
I am having the attached error messages when loading version 2.50.0.  I have used JTAlert for several years with great success, but I am really stuck as to what to do to get 2.50.0 running.  I reloaded the previous version and everything works great.  I am running Windows 10. 

Any help is appreciated.

Glenn
K4ZOT

32bit windows by any chance?

If so this is the problem, recently confirmed.

Until a dedicated 32bit build of JTAlert is produced you will have to stay with JTAlert 2.16.17

de Laurie VK3AMA


locked Error Messages on loading New Version 2.50.0 - need Help

 

I am having the attached error messages when loading version 2.50.0.  I have used JTAlert for several years with great success, but I am really stuck as to what to do to get 2.50.0 running.  I reloaded the previous version and everything works great.  I am running Windows 10. 

Any help is appreciated.

Glenn
K4ZOT


locked Re: JT Alert 2.50.0 stopped by FrameworkCheck

Eric Alchowiak <alchowiake@...>
 

Thanks. 

Here's a capture of FrameworkCheck which might be a clue.

Eric A
KO0V



From: Support@HamApps.groups.io <Support@HamApps.groups.io> on behalf of HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
Sent: Wednesday, April 21, 2021 7:21 PM
To: Support@HamApps.groups.io <Support@HamApps.groups.io>
Subject: Re: [HamApps] JT Alert 2.50.0 stopped by FrameworkCheck
 
On 22/04/2021 8:56 am, Eric Alchowiak wrote:
No. Net 5 installed just fine. 2.50 just refuses to start and generates a litany of error messages. 

Like I said 32 bit windows 10. 

Eric A 
KO0V

OK Eric,

32 bit (x86) appears to be the common denominator.

The litany of error messages I assume are "AutoIT errors" after trying to start JTAlert. That is a side-effect of trying to run JTAlert without the critical Manager process running. The Manager, like the FrameworkCheck file, is dependent on the new NET runtime and compiled as "Any CPU" executables.

While JTAlert 2.50.0 and the FrameworkCheck app are compiled as "Any CPU" applications, which means they will execute as either x86 or x64 depending on the bitness of your Windows version, I suspect this is not the case and something is preventing the executables from running under 32 bit Windows.

I am working with a JTAlert Test Team member who has a 32bit Win10 system that is also experiencing the same problem.

At this time, the only course of action is for 32 bit Windows users to stay with JTAlert 2.16.17 and oinly upgrade once a new 32bit compatible version of JTAlert is published.

Sorry for the inconvenience.

de Laurie VK3AMA



locked Re: JT Alert 2.50.0 stopped by FrameworkCheck

HamApps Support (VK3AMA)
 

On 22/04/2021 8:56 am, Eric Alchowiak wrote:
No. Net 5 installed just fine. 2.50 just refuses to start and generates a litany of error messages. 

Like I said 32 bit windows 10. 

Eric A 
KO0V

OK Eric,

32 bit (x86) appears to be the common denominator.

The litany of error messages I assume are "AutoIT errors" after trying to start JTAlert. That is a side-effect of trying to run JTAlert without the critical Manager process running. The Manager, like the FrameworkCheck file, is dependent on the new NET runtime and compiled as "Any CPU" executables.

While JTAlert 2.50.0 and the FrameworkCheck app are compiled as "Any CPU" applications, which means they will execute as either x86 or x64 depending on the bitness of your Windows version, I suspect this is not the case and something is preventing the executables from running under 32 bit Windows.

I am working with a JTAlert Test Team member who has a 32bit Win10 system that is also experiencing the same problem.

At this time, the only course of action is for 32 bit Windows users to stay with JTAlert 2.16.17 and oinly upgrade once a new 32bit compatible version of JTAlert is published.

Sorry for the inconvenience.

de Laurie VK3AMA



locked Re: JTAlert 2.50 Won't start

Eric Alchowiak <alchowiake@...>
 

It's a 32 bit system with 8 gig of ram. 

Eric A 
NO0V


From: Support@HamApps.groups.io <Support@HamApps.groups.io> on behalf of HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
Sent: Wednesday, April 21, 2021 5:28 PM
To: Support@HamApps.groups.io <Support@HamApps.groups.io>
Subject: Re: [HamApps] JTAlert 2.50 Won't start
 
On 21/04/2021 12:33 pm, alchowiake@... wrote:
I have windows 10 with ALL Microsoft updates installed. I have Net 5 runtime installed but when I load 2.50 Frameworkcheck says "This app can't run on your PC" and a bunch of other random error messages follow.

OM (name? Callsign?)

Is this on a 32bit or 64bit system?

de Laurie VK3AMA


locked Re: JT Alert 2.50.0 stopped by FrameworkCheck

alchowiake@...
 

No. Net 5 installed just fine. 2.50 just refuses to start and generates a litany of error messages. 

Like I said 32 bit windows 10. 

Eric A 
KO0V


From: Support@HamApps.groups.io <Support@HamApps.groups.io> on behalf of HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
Sent: Wednesday, April 21, 2021 5:32 PM
To: Support@HamApps.groups.io <Support@HamApps.groups.io>
Subject: Re: [HamApps] JT Alert 2.50.0 stopped by FrameworkCheck
 
On 22/04/2021 4:35 am, alchowiake@... wrote:
I have 32bit Windows 10 Home version 20H2 (which is the latest) with Net 5 and FrameworkCheck claims it's incompatible with my system so I can't get 2.50 to run. If I try to ignore this and run 2.50 anyway it just generates a bunch of error messages.

Are you saying the .NET 5 Desktop Runtime will not install due to an incompatibility error? That should not be the case, unless you're trying to install the X64 version when it needs to be the X86 version for 32bit Windows.

JTAlert throwing errors is inevitable if the .NET 5 Desktop Runtime is not installed. The runtime is not optional it is mandatory for correct JTAlert 2.50.0 operation.


de Laurie VK3AMA


locked Re: Feature suggestion for variable filters for multiple instances #FT8

HamApps Support (VK3AMA)
 

On 22/04/2021 6:29 am, Pat N6PAT via groups.io wrote:

My idea is to have the ability to configure numerous filters on the settings page and save them under unique names such as Just NA, NA LOTW, EU eQSL, CQ Only, etc.These would be created on the main settings page and could be made available to each instance via a drop down list at the bottom of the Call Sign Window.

Per instance profiles will be coming, but likely not until all the old code and its monolithic Settings window and settings file are replaced.  That is not any time soon.

But, what you want with per instance filtering is already available but not remembered across restarts. Rather than going into the Settings and making filter changes which then requires restarting all your instances, simply use the "Alerts -> Filters" menu of each JTAlert window. That menu selection can be done on a per instance basis but will need to be reselected when you next start JTAlert. FYI, that menu selection has been available for several years, it is not new.

de Laurie VK3AMA


locked Re: Feature suggestion - option to partition call window for DX vs Domestic #FT8

HamApps Support (VK3AMA)
 

On 21/04/2021 1:19 pm, Pat N6PAT via groups.io wrote:
Another from my wish list:

An option to allow splitting DX vs domestic call signs into separate partitions within the call sign window. Allow the user to turn  the option on or off as they wish.

What do you think?

That's coming, not in the next release, but soon after.

The next release has had a significant amount of internal changes to the Callsigns window to allow for varying the size of the Callers panel, which currently is single line or column only. This introduces a user-draggable divider between the two views. While not a significant change for most users who don't experience pileups where the number of callers exceeds the visual capacity of the Callers display without the need for scrolling, it is of benefit to users who do and want to see more than one line or column of callers.

These changes have introduced a new underlying code framework (no its not a new MS framework, its my own code) that allows for easier expansion of the Callsigns window into multiple views beyond the hard limit of 2 currently. I expect to initially provide 3 or 4 views in the Callsigns window with a choice or either horizontal or vertical splitting of the Callsigns window.

While adding extra views is now much simpler, there is still the code (and logic) that needs to be written to route the callsigns to the correct view, and then the  UI  to allow the user to setup which decode types get routed to which view. This is why multiple views will not be available with the next release.

Be assured, it is happening, and is currently being worked on.

de Laurie VK3AMA


locked Re: Line 10385

HamApps Support (VK3AMA)
 

On 21/04/2021 7:57 am, gabriel.dulcu@... wrote:
Config - Windows 10 Home - 64-bit up-to-date and WSJT-X 2.3.0
JTAlert 2.50.0 is crashing at every launch after 10-60 s with
Line 10385 Error: Variable used without being declared.
Please advise.

Thanks in advance,
73 de M0JHV Gabriel

What happens if you temporarily turn off monitor in wsjtx so there are no incoming decodes are being fed to JTAlert, does JTAlert still show this error?

Is it always the same line number?

Line numbers shown in these type of errors are typically not correct as is the type of error, there are no undefined variables in the code. One of the many reasons why the old AutoIT code is being replaced.

I suggest you try starting JTAlert without a config file. There may be something in the config that is tripping up JTAlert. See the JTAlert Help file (not the 2.50.0 features help), "Troubleshooting -> Setting Changes Not Remembered" topic. It explains where to find the config file. It may be worth trying to restore an old backup of the config.sqlite file, explained in that help topic, before proceeding to starting JTAlert without a config file.

If starting JTAlert without a config file corrects the problem, I would greatly appreciate it if you could send me the problem config.sqlite file for examination. send it direct (not via this group) to VK3AMA.Ham.Apps [at] gmail.com

let me know your results.

de Laurie VK3AMA


locked Re: Alert Filtering enhancement ...

HamApps Support (VK3AMA)
 

On 21/04/2021 6:29 am, Joe Subich, W4TV wrote:
As you move more of the code into the NET framework, please consider
making the alert filtering band specific.  Specifically, I turn *OFF*
"Show only Callsign generating alerts" on bands with little activity
(e.g. 6m, 12m, etc.) but turn it *ON* for crowded bands (e.g. 20m, 40m,
sometimes 30m, etc.).  It would be nice to have that setting (and the
distance in "Do not show NON ALERTING callsigns under this distance")
be restored to band specific values when returning to a band.

73,

  ... Joe, W4TV

Its on my list.
When its coded you will see it first in the Test Team group.

de Laurie VK3AMA




locked Re: Wildcard in Wanted Callsign - not triggered?

HamApps Support (VK3AMA)
 

On 22/04/2021 5:42 am, Tomas, NW7US wrote:
I have added the following callsigns and callsign prefixes with wildcard into the Wanted Callsign Alert list.

When a callsign is decoded in the CQ period, that matches a wildcard callsign prefix, JTAlert does not alert.

Here is a screen grab of my settings and the CQ decode:

A screen-grab showing the JTAlert window would have been more useful. A side-by-side comparison of JTAlert and WSJT-X at the time of the error would be more useful for diagnosis.

Did the Wanted Callsign show in the JTAlert window? Did it show the Wanted Callsign coloring?
Your screen-grab shows the decodes for the callsign several periods earlier, which would be long gone from the main JTAlert window. Are you sure you didn't just miss the audio announcement?

Does this happen on all your Wanted Callsigns, or just this one time?

Check that you have not inadvertently placed that callsign in the Ignored list.

de Laurie VK3AMA


locked Re: JT Alert 2.50.0 stopped by FrameworkCheck

HamApps Support (VK3AMA)
 

On 22/04/2021 4:35 am, alchowiake@... wrote:
I have 32bit Windows 10 Home version 20H2 (which is the latest) with Net 5 and FrameworkCheck claims it's incompatible with my system so I can't get 2.50 to run. If I try to ignore this and run 2.50 anyway it just generates a bunch of error messages.

Are you saying the .NET 5 Desktop Runtime will not install due to an incompatibility error? That should not be the case, unless you're trying to install the X64 version when it needs to be the X86 version for 32bit Windows.

JTAlert throwing errors is inevitable if the .NET 5 Desktop Runtime is not installed. The runtime is not optional it is mandatory for correct JTAlert 2.50.0 operation.


de Laurie VK3AMA


locked Re: JTAlert 2.50 Won't start

HamApps Support (VK3AMA)
 

On 21/04/2021 12:33 pm, alchowiake@... wrote:
I have windows 10 with ALL Microsoft updates installed. I have Net 5 runtime installed but when I load 2.50 Frameworkcheck says "This app can't run on your PC" and a bunch of other random error messages follow.

OM (name? Callsign?)

Is this on a 32bit or 64bit system?

de Laurie VK3AMA


locked Re: Moving "QSO Logged" window?

HamApps Support (VK3AMA)
 

On 21/04/2021 10:38 pm, Bill - AA4M wrote:
That gave me an idea.  I moved the main JTAlert window around until it resulted an placing the QSO window where I wanted.  Tedious, but this worked.  But I look forward to a later version of JTAlert when the QSO window can be dragged and will stay where it's placed.

Thanks for this superior software and support Laurie!

73, Bill  AA4M

Bill,

An alternative, if you happy that JTAlert is logging the QSOs reliably without error, is to turn off the "logging success" popup but leave the "logging failure" popup enabled. See the "Window -> Popup Windows" section of the main JTAlert Settings window.

de Laurie VK3AMA


locked Re: No calls are showing up in Callsign window

HamApps Support (VK3AMA)
 

On 21/04/2021 12:06 pm, Charlie Rubenstein wrote:
I upgraded to the newest version, and am not getting any callsigns at all. The title bar shows the correct band, etc, but no decodes or callsigns.

I still have the UDP on port 2237 and all three boxes are checked in WSJT-X.

What am I doing wrong?

de Charlie KB8CR

See my answer to the other thread you started.
https://hamapps.groups.io/g/Support/message/34571

de Laurie VK3AMA


locked Re: Not having luck with UDP settings

HamApps Support (VK3AMA)
 

On 22/04/2021 3:46 am, Charlie Rubenstein wrote:
I have had no luck (execpt once when it spontaneously started working for a while) getting the decodes and callsigns to show up from WSJT-X.

Here are the settings from the "About window"
JTAlert Instance       : #1
JTAlert Start Params   : /wsjtx
WSJT-X Window Title    : WSJT-X   v2.3.1   by K1JT, G4WJS, and K9AN
WSJT-X Command Line    : "C:\WSJT\wsjtx\bin\wsjtx.exe" 
WSJT-X   --rig-name    : 
WSJT-X Config File     : C:\Users\KB8CR\AppData\Local\WSJT-X\WSJT-X.ini
WSJT-X Version         : 2.3.1
WSJT-X Revision        : 0e7224
WSJT-X Spec Op Mode    : None
WSJT-X UDP ID          : WSJT-X
WSJT-X UDP Port        : 2237
WSJT-X UDP Server      : 127.0.0.1
WSJT-X UDP MCast on LB : True
WSJT-X UDP Max Schema  : 3
 
Any help would be greatly appreciated.. I also can't get it to write logs to my HRD 6 logbook which worked fine before the upgrade.

73 de Charlie KB8CR

I see your using a Flex, does that indicate you're running multiple instances of JTAlert? If so, since you're using a unicast UDP address (127.0.0.1) you will need to give each WSJT-X a unique UDP port value, they cannot all be 2237. Setting to use multicast is a better solution than setting each wsjtx configuration to use a unique port.

If you're only running a single JTAlert instance, then likely you have another application trying to work with wsjtx and it is taking exclusive control of the port. In that situation, your best to configure wsjtx to use multicast UDP. See the JTAlert help file "WSJT-X UDP Setup" topic for correct wsjtx and jtalert setup. You will also need configure any other applications trying to work with wsjtx directly to us multicast as well.

My strong advice, regardless of whether you're running single or multiple instances is to use Multicast UDP.

de Laurie VK3AMA


locked Feature suggestion for variable filters for multiple instances #FT8

Pat N6PAT
 

I use a Flex 6700 which allows using up to 8 receivers (slices in Flex terminology) for different band/mode configurations  simultaneously.  I usually monitor 6 bands at the same time with each receiver having it's own JTAlert instance.

Currently, the filter criteria is configured on the settings page and all instances are controlled by the same single filter criteria. There is no independence between the instances.

My idea is to have the ability to configure numerous filters on the settings page and save them under unique names such as Just NA, NA LOTW, EU eQSL, CQ Only, etc.These would be created on the main settings page and could be made available to each instance via a drop down list at the bottom of the Call Sign Window.

So with that option in place I could have Receiver A dedicated to DX only , Receiver B for NA, Receiver C for EU, etc.or I could turn off the filter  on any or all instance with either a toggle switch or by selecting No Filter in the drop down list for a given receiver while not impacting other active receivers. This would be a major benefit for Flex users in particular but also for anyone running more than a single JTAlert instance

Another advantage would be eliminating the need to go back to the settings page to select a different filter or turn the filters off during operation. That could be done via the drop box.


locked Wildcard in Wanted Callsign - not triggered?

 

Greetings.

I have added the following callsigns and callsign prefixes with wildcard into the Wanted Callsign Alert list.

When a callsign is decoded in the CQ period, that matches a wildcard callsign prefix, JTAlert does not alert.

Here is a screen grab of my settings and the CQ decode:



Am I doing this incorrectly?

Thanks,

73 de NW7US dit dit

SKCC Nr. 4758s / FISTS Nr. 7055 / LICW Nr. 653 
NW7US on QRZ / NW7US on YouTubeTwitterFacebookBlog
Space weather and radio propagation editor for 
      - CQ Amateur Radio Magazine, and,
      - The Spectrum Monitor magazine. 

..


locked Re: JT Alert 2.50.0 stopped by FrameworkCheck

alchowiake@...
 

I have 32bit Windows 10 Home version 20H2 (which is the latest) with Net 5 and FrameworkCheck claims it's incompatible with my system so I can't get 2.50 to run. If I try to ignore this and run 2.50 anyway it just generates a bunch of error messages.

2881 - 2900 of 37225