Date   

locked Re: [Request] menu for "lookups" for Log4OM2

Rick VK6RK
 

Hi Kiyo,

This is different to Worked before (F10).

It opens another window, similar to below.
Columns are customisable just like other Log4OM windows.


73, Rick VK6RK

On 15/07/2021 10:18, kiyo wrote:
Hi Rick
Thank you.
I know about worked before (F10).
If possible, I wanted to display the window without putting it in
focus, just like with DXKeeper.

--
kiyo

2021年7月15日(木) 10:45 Rick VK6RK <rick@...>:
Hi Kiyo,

Just open the Worked Before window, using View - Worked before.  It will stay open all the time and show multiple worked before entries, for that particular call.

73, Rick VK6RK

On 15/07/2021 09:22, kiyo wrote:

Hello.
I recently changed from DXKeeper to Log4OM2. JTAlert is very comfortable to use.

The slightly inconvenient point is that it is troublesome to know the past QSO status immediately. Isn't the "DX Lab lookups" menu provided for DXkeeper also available for Log4OM2?

When you actually call the DX station, the character string is placed in the call sign of the other party of Log4OM2, so it does not seem to be so difficult compared to DX Keeper. If this menu addition is realized, Log4OM2 users will be happy because they can see the past QSO status by the same operation as DXKeeper before actually calling operation. In that case, there is no need to press "worked before (F10)" in the Log4OM2 window.

Please consider it.

I'm using:
WSJT-X 2.3.0 (I use this to avoid a bug that Tx5 generated by JTAlert is not sent when Tx4 is RRR)
JTAlert 2.50.4
Log4OM2

-
kiyo


locked Re: [Request] menu for "lookups" for Log4OM2

kiyo
 

Hi Rick
Thank you.
I know about worked before (F10).
If possible, I wanted to display the window without putting it in
focus, just like with DXKeeper.

--
kiyo

2021年7月15日(木) 10:45 Rick VK6RK <rick@vk6xlr.net>:


Hi Kiyo,

Just open the Worked Before window, using View - Worked before. It will stay open all the time and show multiple worked before entries, for that particular call.

73, Rick VK6RK

On 15/07/2021 09:22, kiyo wrote:

Hello.
I recently changed from DXKeeper to Log4OM2. JTAlert is very comfortable to use.

The slightly inconvenient point is that it is troublesome to know the past QSO status immediately. Isn't the "DX Lab lookups" menu provided for DXkeeper also available for Log4OM2?

When you actually call the DX station, the character string is placed in the call sign of the other party of Log4OM2, so it does not seem to be so difficult compared to DX Keeper. If this menu addition is realized, Log4OM2 users will be happy because they can see the past QSO status by the same operation as DXKeeper before actually calling operation. In that case, there is no need to press "worked before (F10)" in the Log4OM2 window.

Please consider it.

I'm using:
WSJT-X 2.3.0 (I use this to avoid a bug that Tx5 generated by JTAlert is not sent when Tx4 is RRR)
JTAlert 2.50.4
Log4OM2

-
kiyo



locked Re: [Request] menu for "lookups" for Log4OM2

Rick VK6RK
 

Jim,

Should have mentioned that "View - Worked before" was for Log4OM.

True, you can use F6 in JTSAlert however Log4OM gives more comprehensive info.

73, Rick VK6RK

On 15/07/2021 10:03, Jim Cooper wrote:
On 15 Jul 2021 at 9:44, Rick VK6RK wrote:

Just open the Worked Before window, using View - Worked before. It
will stay open all the time and show multiple worked before entries,
for that particular call.

73, Rick VK6RK
Rick, what version of JTalert are you using?

I am using 2.50.4 and under View tab it is the 
"Callsign History Window F6" ... the window 
itself has the title "QSO History" and shows 
all QSOs with that call using the mode you are 
currently using. 

w2jc


locked Re: [Request] menu for "lookups" for Log4OM2

Jim Cooper
 

On 15 Jul 2021 at 9:44, Rick VK6RK wrote:

Just open the Worked Before window, using View - Worked before. It
will stay open all the time and show multiple worked before entries,
for that particular call.

73, Rick VK6RK
Rick, what version of JTalert are you using?

I am using 2.50.4 and under View tab it is the
"Callsign History Window F6" ... the window
itself has the title "QSO History" and shows
all QSOs with that call using the mode you are
currently using.

w2jc


locked Re: [Request] menu for "lookups" for Log4OM2

Rick VK6RK
 

Hi Kiyo,

Just open the Worked Before window, using View - Worked before.  It will stay open all the time and show multiple worked before entries, for that particular call.

73, Rick VK6RK

On 15/07/2021 09:22, kiyo wrote:
Hello.
I recently changed from DXKeeper to Log4OM2. JTAlert is very comfortable to use.

The slightly inconvenient point is that it is troublesome to know the past QSO status immediately. Isn't the "DX Lab lookups" menu provided for DXkeeper also available for Log4OM2?

When you actually call the DX station, the character string is placed in the call sign of the other party of Log4OM2, so it does not seem to be so difficult compared to DX Keeper. If this menu addition is realized, Log4OM2 users will be happy because they can see the past QSO status by the same operation as DXKeeper before actually calling operation. In that case, there is no need to press "worked before (F10)" in the Log4OM2 window.

Please consider it.

I'm using:
WSJT-X 2.3.0 (I use this to avoid a bug that Tx5 generated by JTAlert is not sent when Tx4 is RRR)
JTAlert 2.50.4
Log4OM2

-
kiyo


locked [Request] menu for "lookups" for Log4OM2

kiyo
 

Hello.
I recently changed from DXKeeper to Log4OM2. JTAlert is very comfortable to use.

The slightly inconvenient point is that it is troublesome to know the past QSO status immediately. Isn't the "DX Lab lookups" menu provided for DXkeeper also available for Log4OM2?

When you actually call the DX station, the character string is placed in the call sign of the other party of Log4OM2, so it does not seem to be so difficult compared to DX Keeper. If this menu addition is realized, Log4OM2 users will be happy because they can see the past QSO status by the same operation as DXKeeper before actually calling operation. In that case, there is no need to press "worked before (F10)" in the Log4OM2 window.

Please consider it.

I'm using:
WSJT-X 2.3.0 (I use this to avoid a bug that Tx5 generated by JTAlert is not sent when Tx4 is RRR)
JTAlert 2.50.4
Log4OM2

-
kiyo


locked Re: JTAlert version 2.50.4

Robert Lorenzini
 

Well I hope so, Laurie needs a vacation after the last week.

Bob - wd6dod

On 7/14/2021 5:26 PM, Jamie GOLLY wrote:
Just downloaded and installed. Works Fantastic!!!


Thank you Laurie and team, this should make people happy.



Jamie
K6NGN


locked JTAlert version 2.50.4

Jamie GOLLY
 

Just downloaded and installed. Works Fantastic!!!


Thank you Laurie and team, this should make people happy.



Jamie
K6NGN


locked Re: Callsign window gone after update to 2.5.3

W9WO
 

Hi Laurie.
 
 Thanks for your quick and dedicated attention to my/our problem with 2.50.3. I just installed 2.50.4 and all of my previous issues appear to be resolved. Callsign window is now working as it should for certain.
 
73,
Darrell W9WO
 


locked Is there an update order of priority for upgrading programs ?

Bob Frostholm
 

Hi Laurie,

I've been reading to emails today about the new versions of so many pieces of software. I'm waiting for the dust to settle before leaping in but I do want to ask if there is a particular order in which the pieces should be updated... or does it not make any difference.

I am currently operating the following (all older versions):

Net 5.0.8 (KB5004698)

JTAlert 2.50.0

WSJT-x v2.2.2

This combination works pretty well, although I have noticed that when I work a new grid on 6M and confirm that the contact is correct in both JTAlert and WSJT-x .adi logs that grid does not show up in the no longer Wanted Grids page even after I initiate rebuild alerts database. I have to exit JTAlert,(which also properly closes WSJT-x) restart it  (often several times) before the grid shows... time duration has been up to 30 minutes on occasion during which I'm being told about new grids I'm decoding that are not really new.... Hopefully it's the result of my combination of "not" up to date versions of the programs.

Example. it took over an hour for IL18 to appear this AM. I had only 1 other program running: Thunderbird email program

Computer is HP Pavilion dv6

Storage is 1TB SSD (with about 600GB available)

Windows 7 Ultimate 64 bit

Cheers


73

Bob

Ko6Lu


--
Bob
KO6LU


locked #Announcement #NewRelease : JTAlert 2.50.4 is available - Critical defect fix #Announcement #NewRelease

HamApps Support (VK3AMA)
 

The latest JTAlert version 2.50.4 is now available @ https://hamapps.com/JTAlert/ <https://hamapps.com/JTAlert/>

This release corrects a defect with 2.50.3 that prevented some users from opening the Callsigns window along with failed sound and UDP comms.

de Laurie VK3AMA

Release Notes.

2.50.4 (2021-Jul-15)

  *** Includes Callsign database file version 2021-07-12 (2021-Jul-12)

  Fixes:

    Miscellaneous crtical faults: Callsigns window and other 2.50.x series windows
     not opening, no sound, no UDP comms with WSJT-X. JTAlertV2.Manager.exe process
     continually stopping and starting. This did not affect all JTAlert users.
     (2.50.3 defect)


locked Re: 2.50.3 Hotfix

HamApps Support (VK3AMA)
 

On 15/07/2021 8:24 am, Pat N6PAT via groups.io wrote:
Does the install package include the fix now? I haven't upgraded yet and was wondering if I would need to apply the fix after the install or if the install package has now been modified to address the issue.

73 Pat N6PAT

What install package?
I have 2.50.4 nearly ready to release, it has the fix. But the current 2.50.3 release does not. I am going to release 2.50.4 within the hour.

de Laurie VK3AMA


locked Re: 2.50.3 Hotfix

Pat N6PAT
 

Laurie,

Does the install package include the fix now? I haven't upgraded yet and was wondering if I would need to apply the fix after the install or if the install package has now been modified to address the issue.

73 Pat N6PAT


locked Re: JTDX issues with latest JTAlert release. #JTDX

Alan Sorum WL7CG
 

All,

The posted fix works. Thanks!

73 Alan WL7CG


locked Re: New JTalert 2.50.3 missing callsign window

Jim Wysocki
 

For everyone's information, I downloaded the missing file using the directions in one of Laurie's latest support postings.  Adding that file to the proper config directory location fixes the problem and now JTAlert is working perfectly.

Many thanks to Laurie for some speedy and detailed diagnostics and resolution work.  What an outstanding job!

73,  Jim  W9FI

On 7/14/2021 2:08 PM, Jim Wysocki wrote:

Excellent news, indeed.  I'll wait for the latest version to be published before doing anything else.

Thanks and 73,  Jim  W9FI

On 7/14/2021 2:04 PM, HamApps Support (VK3AMA) wrote:
On 15/07/2021 12:34 am, Michael Black via groups.io wrote:
We renamed his HamApps directory to start a new config and everything is working now.

So there's a corruption in the config.

Renaming the directory should not have worked. I was able to reproduce the problem by deleting the Callsigns_1.config file. Which is essentially the same as renaming the directory for that part of the code that was throwing an exception.

It turns out it was a cross-threading style exception involving the changes I made to the Callsign symbols not sticking.
I can now reproduce the defect at will.

I'm preparing a new build, 2.50.4, as I expect many wont be able to follow the published fix of replacing the defective Callsigns_1.config file.


de Laurie VK3AMA


locked Re: New JTalert 2.50.3 missing callsign window

Jim Wysocki
 

Excellent news, indeed.  I'll wait for the latest version to be published before doing anything else.

Thanks and 73,  Jim  W9FI

On 7/14/2021 2:04 PM, HamApps Support (VK3AMA) wrote:
On 15/07/2021 12:34 am, Michael Black via groups.io wrote:
We renamed his HamApps directory to start a new config and everything is working now.

So there's a corruption in the config.

Renaming the directory should not have worked. I was able to reproduce the problem by deleting the Callsigns_1.config file. Which is essentially the same as renaming the directory for that part of the code that was throwing an exception.

It turns out it was a cross-threading style exception involving the changes I made to the Callsign symbols not sticking.
I can now reproduce the defect at will.

I'm preparing a new build, 2.50.4, as I expect many wont be able to follow the published fix of replacing the defective Callsigns_1.config file.


de Laurie VK3AMA


locked Re: Problems with JTAlert latest install

HamApps Support (VK3AMA)
 

On 15/07/2021 6:57 am, Michael Black via groups.io wrote:
Shut down JTAlert and try renaming the HamApps directory then start JTAlert again.

See if that fixes the problem.

Mike W9MDB

No! That wont work. That has the same effect as deleting the problematic Callsigns_1.config file which will still cause the Manager process to fault when trying to open the Callsigns window.

Using the Callsigns_1.config file included in this post is the fix. https://hamapps.groups.io/g/Support/message/36310

de Laurie VK3AMA



locked Re: Decodes window: View->Clear Display has no effect

Michael Black
 

Try

HamApps\JTAlert\KX9Q\Config

Mike W9MDB


On Wednesday, July 14, 2021, 04:03:24 PM CDT, Don - kx9q <don@...> wrote:


Hi Laurie

 

When I installed v2.50.3  I was informed the correct version of .NET 5.0 Desktop Runtime (v5.0.8) – Windows x64 was already installed.  I proceeded and Callsign window did not open up.  I then followed your instructions listed an email , however, I am not able to read the SQLite format 3 very well using Notepad+ +.  I ran a search for “<your_callsign>” but found no matches.  Am I looking at the correct config file - config.splite?  See attached file

Prior to upgrading to 2.50..3 I was using 2.50.1 without issues.

 

Don – kx9q


locked Re: New JTalert 2.50.3 missing callsign window

HamApps Support (VK3AMA)
 

On 15/07/2021 12:34 am, Michael Black via groups.io wrote:
We renamed his HamApps directory to start a new config and everything is working now.

So there's a corruption in the config.

Renaming the directory should not have worked. I was able to reproduce the problem by deleting the Callsigns_1.config file. Which is essentially the same as renaming the directory for that part of the code that was throwing an exception.

It turns out it was a cross-threading style exception involving the changes I made to the Callsign symbols not sticking.
I can now reproduce the defect at will.

I'm preparing a new build, 2.50.4, as I expect many wont be able to follow the published fix of replacing the defective Callsigns_1.config file.


de Laurie VK3AMA


locked Re: Decodes window: View->Clear Display has no effect

Don - kx9q
 

Hi Laurie

 

When I installed v2.50.3  I was informed the correct version of .NET 5.0 Desktop Runtime (v5.0.8) – Windows x64 was already installed.  I proceeded and Callsign window did not open up.  I then followed your instructions listed an email , however, I am not able to read the SQLite format 3 very well using Notepad+ +.  I ran a search for “<your_callsign>” but found no matches.  Am I looking at the correct config file - config.splite?  See attached file

Prior to upgrading to 2.50..3 I was using 2.50.1 without issues.

 

Don – kx9q

1581 - 1600 of 37662