Re: [wsjt-devel] wsjt-devel Digest, Vol 80, Issue 19

[Neil Zampella]

Um .. not sure what that is supposed to show.   It shows that you're on
6 meters.  If someone is reporting you on 60 m, that's their problem,
they're reporting you incorrectly.  Has nothing to do with PSK Reporter.

Neil, KN3ILZ


On 10/4/2020 8:06 PM, wsjt-devel-requ...@lists.sourceforge.net wrote:

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."

Today's Topics:

1. PSKReporter---V.2.3.0-rc1 (Pino Zollo)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] PSKReporter---V.2.3.0-rc1

[Pino Zollo]

I am on 6m but pskreporter receives my working conditions on 60m

73

Pino ZP4KFX

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Set file version in program resources (edited]

[Sam W2JDB via wsjt-devel]

Glad I was able to help.
73,

Sam W2JDB


-Original Message-
From: Al Kozakiewicz 
To: Sam W2JDB ; wsjt-devel@lists.sourceforge.net 

Sent: Sun, Oct 4, 2020 4:55 pm
Subject: RE: [wsjt-devel] Set file version in program resources (edited]

#yiv4960261309 #yiv4960261309 -- _filtered {} _filtered {} _filtered {} 
_filtered {}#yiv4960261309 #yiv4960261309 p.yiv4960261309MsoNormal, 
#yiv4960261309 li.yiv4960261309MsoNormal, #yiv4960261309 
div.yiv4960261309MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv4960261309
 a:link, #yiv4960261309 span.yiv4960261309MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv4960261309 a:visited, #yiv4960261309 
span.yiv4960261309MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv4960261309 p 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv4960261309
 p.yiv4960261309msonormal, #yiv4960261309 li.yiv4960261309msonormal, 
#yiv4960261309 div.yiv4960261309msonormal 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv4960261309
 p.yiv4960261309msochpdefault, #yiv4960261309 li.yiv4960261309msochpdefault, 
#yiv4960261309 div.yiv4960261309msochpdefault 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv4960261309
 p.yiv4960261309msonormal1, #yiv4960261309 li.yiv4960261309msonormal1, 
#yiv4960261309 div.yiv4960261309msonormal1 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv4960261309
 p.yiv4960261309msochpdefault1, #yiv4960261309 li.yiv4960261309msochpdefault1, 
#yiv4960261309 div.yiv4960261309msochpdefault1 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv4960261309
 span.yiv4960261309msohyperlink {}#yiv4960261309 
span.yiv4960261309msohyperlinkfollowed {}#yiv4960261309 
span.yiv4960261309msohyperlink1 {}#yiv4960261309 
span.yiv4960261309msohyperlinkfollowed1 {}#yiv4960261309 
span.yiv4960261309emailstyle181 {}#yiv4960261309 span.yiv4960261309emailstyle28 
{}#yiv4960261309 p.yiv4960261309msonormal2, #yiv4960261309 
li.yiv4960261309msonormal2, #yiv4960261309 div.yiv4960261309msonormal2 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv4960261309 
span.yiv4960261309msohyperlink2 
{color:blue;text-decoration:underline;}#yiv4960261309 
span.yiv4960261309msohyperlinkfollowed2 
{color:purple;text-decoration:underline;}#yiv4960261309 
p.yiv4960261309msochpdefault2, #yiv4960261309 li.yiv4960261309msochpdefault2, 
#yiv4960261309 div.yiv4960261309msochpdefault2 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv4960261309 
p.yiv4960261309msonormal11, #yiv4960261309 li.yiv4960261309msonormal11, 
#yiv4960261309 div.yiv4960261309msonormal11 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv4960261309 
span.yiv4960261309msohyperlink11 
{color:blue;text-decoration:underline;}#yiv4960261309 
span.yiv4960261309msohyperlinkfollowed11 
{color:purple;text-decoration:underline;}#yiv4960261309 
span.yiv4960261309emailstyle1811 {color:#1F497D;}#yiv4960261309 
p.yiv4960261309msochpdefault11, #yiv4960261309 li.yiv4960261309msochpdefault11, 
#yiv4960261309 div.yiv4960261309msochpdefault11 
{margin-right:0in;margin-left:0in;font-size:10.0pt;}#yiv4960261309 
span.yiv4960261309emailstyle281 {color:#1F497D;}#yiv4960261309 
span.yiv4960261309EmailStyle38 {color:#1F497D;}#yiv4960261309 
.yiv4960261309MsoChpDefault {} _filtered {}#yiv4960261309 
div.yiv4960261309WordSection1 {}#yiv4960261309 _filtered {} _filtered {} 
_filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} 
_filtered {} _filtered {}#yiv4960261309 ol {margin-bottom:0in;}#yiv4960261309 
ul {margin-bottom:0in;}#yiv4960261309 That will work. I had searched through 
the registry prior to this request but found that you needed to know the 
version number for the key before you could find the version number value.    
I’ll make the case the adding the file resources is best practice – installers 
often use it in order to decide whether to replace a file – but right now I 
just want to use a more determinative way than inference to figure out what to 
do.    Thanks!    Al AB2ZY    From: Sam W2JDB [mailto:w2...@aol.com]
Sent: Sunday, October 04, 2020 4:44 PM
To: wsjt-devel@lists.sourceforge.net; Al Kozakiewicz
Subject: Re: [wsjt-devel] Set file version in program resources (edited]    Hi, 
   Well, there is another way to get the version number. Its a bit of a kludge 
but it can be done. Search and find a file in the 
..\Share\doc\WSJT-X\wsjtx--main-*.html The version number is the wildcard 
value. Simple enough code to write. If there is a will there is way, sometimes. 
    73,    Sam W2JDB    -Original Message-
From: Al Kozakiewicz 
To: Sam W2JDB ; WSJT software development 

Sent: Sun, Oct 4, 2020 4:25 pm
Subject: RE: [wsjt-devel] Set file version in program resources Correct. The 
file version resource needs to be added.   If you are using an IDE like Visual 
Studio you can add the resource as a project property and, once added, 

Re: [wsjt-devel] Set file version in program resources (edited]

[Al Kozakiewicz]

That will work. I had searched through the registry prior to this request but 
found that you needed to know the version number for the key before you could 
find the version number value.

I’ll make the case the adding the file resources is best practice – installers 
often use it in order to decide whether to replace a file – but right now I 
just want to use a more determinative way than inference to figure out what to 
do.

Thanks!

Al
AB2ZY

From: Sam W2JDB [mailto:w2...@aol.com]
Sent: Sunday, October 04, 2020 4:44 PM
To: wsjt-devel@lists.sourceforge.net; Al Kozakiewicz
Subject: Re: [wsjt-devel] Set file version in program resources (edited]

Hi,

Well, there is another way to get the version number. Its a bit of a kludge but 
it can be done.
Search and find a file in the ..\Share\doc\WSJT-X\wsjtx--main-*.html
The version number is the wildcard value.
Simple enough code to write. If there is a will there is way, sometimes.

73,

Sam W2JDB

-Original Message-
From: Al Kozakiewicz 
To: Sam W2JDB ; WSJT software development 

Sent: Sun, Oct 4, 2020 4:25 pm
Subject: RE: [wsjt-devel] Set file version in program resources
Correct. The file version resource needs to be added.

If you are using an IDE like Visual Studio you can add the resource as a 
project property and, once added, set it either in VS or during your make 
process.

Otherwise, there are plenty of tools available that can add the resource and 
set the value outside the development tool.

Al
AB2ZY

From: Sam W2JDB via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Sent: Sunday, October 04, 2020 4:20 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Sam W2JDB
Subject: Re: [wsjt-devel] Set file version in program resources

Hi Al,

I don't believe the file version or product version is carried by the 
executable.
Easy way to check that out is just by hovering over the file in Windows 
Explorer.
If the data is there, it is displayed. Just tried it and its not being 
displayed.

73,
Sam W2JDB


-Original Message-
From: Al Kozakiewicz 
To: WSJT software development 
Sent: Sun, Oct 4, 2020 3:36 pm
Subject: Re: [wsjt-devel] Set file version in program resources
Launching WSJT is not an issue. It works fine for the many hundreds of users 
who currently use both and N1MM for contesting. The idea is that the ISO 
language code that drives the N1MM localization behavior is what is passed to 
WSJT, regardless of the PC localization settings. If WSJT doesn’t support that 
language, it starts in English, which is fine behavior.

This is not a feature request. No coding is required. We merely would like the 
version information of the Windows .exe file filled out during your make 
process or however you build your solution. I can provide you with a freeware 
tool and instructions to do so.

Best regards,

Al
AB2ZY

From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, October 04, 2020 11:52 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Set file version in program resources

Al,

it seems to me that if you are going to start WSJT-X for the user, btw not sure 
how you are going to do that if it is running on a different host and maybe 
different operating system than Windows, then you must have specific options in 
N1MM Logger+ to allow the user to customize WSJT-X. Surely then the user will 
only request a different UI language for WSJT-X if it happens to not start in 
the one they want, i.e. they will only set the option where it is supported in 
WSJT-X.

We are always going to be reluctant to add features that limit the usage of 
WSJT-X to only one operating system or network configuration, or discourage the 
use of WSJT-X on any of the operating systems supported.

73
Bill
G4WJS.

On 04/10/2020 16:38, Al Kozakiewicz wrote:
On the contrary, it is necessary to support those users who do not wish for 
WSJT to start with the PC’s locale. N1MM is localized and we launch WSJT with 
the same language N1MM is set to, which may not be the same as the PC.

For example, many Japanese users prefer English. Before we made this change, 
N1MM+ would start with English as the language but there was no way to start 
WSJT in any language except Japanese without the use of the –language command.

Al
AB2ZY

From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, October 04, 2020 11:31 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Set file version in program resources

On 04/10/2020 15:56, Al Kozakiewicz wrote:
I’m with the N1MM development team.

We recently added support for the –language= command line token when launching 
WSJT-X. Of course, WSJT  is not backwards compatible, so versions older than 
2.2 error out on launch when appending the command.  I got around the issue by 
checking the last modified date of wsjtx.exe, but this only works as long as 
there is only one version dependence over time. It would be helpful if you set 
the program version 

Re: [wsjt-devel] Set file version in program resources (edited]

[Sam W2JDB via wsjt-devel]

Hi,
Well, there is another way to get the version number. Its a bit of a kludge but 
it can be done.Search and find a file in the 
..\Share\doc\WSJT-X\wsjtx--main-*.htmlThe version number is the wildcard 
value.Simple enough code to write. If there is a will there is way, sometimes. 
73,
Sam W2JDB


-Original Message-
From: Al Kozakiewicz 
To: Sam W2JDB ; WSJT software development 

Sent: Sun, Oct 4, 2020 4:25 pm
Subject: RE: [wsjt-devel] Set file version in program resources

#yiv0591830812 -- filtered {}#yiv0591830812 filtered {}#yiv0591830812 filtered 
{}#yiv0591830812 filtered {}#yiv0591830812 p.yiv0591830812MsoNormal, 
#yiv0591830812 li.yiv0591830812MsoNormal, #yiv0591830812 
div.yiv0591830812MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv0591830812
 a:link, #yiv0591830812 span.yiv0591830812MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv0591830812 a:visited, #yiv0591830812 
span.yiv0591830812MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv0591830812 p 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv0591830812
 p.yiv0591830812msonormal, #yiv0591830812 li.yiv0591830812msonormal, 
#yiv0591830812 div.yiv0591830812msonormal 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv0591830812
 p.yiv0591830812msochpdefault, #yiv0591830812 li.yiv0591830812msochpdefault, 
#yiv0591830812 div.yiv0591830812msochpdefault 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv0591830812
 span.yiv0591830812msohyperlink {}#yiv0591830812 
span.yiv0591830812msohyperlinkfollowed {}#yiv0591830812 
span.yiv0591830812emailstyle18 {}#yiv0591830812 p.yiv0591830812msonormal1, 
#yiv0591830812 li.yiv0591830812msonormal1, #yiv0591830812 
div.yiv0591830812msonormal1 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0591830812 
span.yiv0591830812msohyperlink1 
{color:blue;text-decoration:underline;}#yiv0591830812 
span.yiv0591830812msohyperlinkfollowed1 
{color:purple;text-decoration:underline;}#yiv0591830812 
span.yiv0591830812emailstyle181 {color:#1F497D;}#yiv0591830812 
p.yiv0591830812msochpdefault1, #yiv0591830812 li.yiv0591830812msochpdefault1, 
#yiv0591830812 div.yiv0591830812msochpdefault1 
{margin-right:0in;margin-left:0in;font-size:10.0pt;}#yiv0591830812 
span.yiv0591830812EmailStyle28 {color:#1F497D;}#yiv0591830812 
.yiv0591830812MsoChpDefault {}#yiv0591830812 filtered {}#yiv0591830812 
div.yiv0591830812WordSection1 {}#yiv0591830812 filtered {}#yiv0591830812 
filtered {}#yiv0591830812 filtered {}#yiv0591830812 filtered {}#yiv0591830812 
filtered {}#yiv0591830812 filtered {}#yiv0591830812 filtered {}#yiv0591830812 
filtered {}#yiv0591830812 filtered {}#yiv0591830812 filtered {}#yiv0591830812 
ol {margin-bottom:0in;}#yiv0591830812 ul {margin-bottom:0in;}#yiv0591830812 
Correct. The file version resource needs to be added.    If you are using an 
IDE like Visual Studio you can add the resource as a project property and, once 
added, set it either in VS or during your make process.    Otherwise, there are 
plenty of tools available that can add the resource and set the value outside 
the development tool.    Al AB2ZY    From: Sam W2JDB via wsjt-devel 
[mailto:wsjt-devel@lists.sourceforge.net]
Sent: Sunday, October 04, 2020 4:20 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Sam W2JDB
Subject: Re: [wsjt-devel] Set file version in program resources    Hi Al,    I 
don't believe the file version or product version is carried by the executable. 
Easy way to check that out is just by hovering over the file in Windows 
Explorer. If the data is there, it is displayed. Just tried it and its not 
being displayed.    73, Sam W2JDB       -Original Message-
From: Al Kozakiewicz 
To: WSJT software development 
Sent: Sun, Oct 4, 2020 3:36 pm
Subject: Re: [wsjt-devel] Set file version in program resources Launching WSJT 
is not an issue. It works fine for the many hundreds of users who currently use 
both and N1MM for contesting. The idea is that the ISO language code that 
drives the N1MM localization behavior is what is passed to WSJT, regardless of 
the PC localization settings. If WSJT doesn’t support that language, it starts 
in English, which is fine behavior.   This is not a feature request. No coding 
is required. We merely would like the version information of the Windows .exe 
file filled out during your make process or however you build your solution. I 
can provide you with a freeware tool and instructions to do so.   Best regards, 
  Al AB2ZY   From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, October 04, 2020 11:52 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Set file version in program resources   Al,   it 
seems to me that if you are going to start WSJT-X for the user, btw not sure 
how you are going to do that if it is running on a different host and maybe 
different operating system than Windows, then you must have specific options in 
N1MM 

Re: [wsjt-devel] Set file version in program resources

[Sam W2JDB via wsjt-devel]

Hi,
Well, there is another way to get the version number. Its a bid a kludge but it 
can be done.Search and find a file in the 
..\Share\doc\WSJT-X\wsjtx--main-*.htmlThe version number is the wildcard 
value.Simple enough code to write. If there is a will there is way, sometimes. 
73,
Sam W2JDB


-Original Message-
From: Al Kozakiewicz 
To: Sam W2JDB ; WSJT software development 

Sent: Sun, Oct 4, 2020 4:25 pm
Subject: RE: [wsjt-devel] Set file version in program resources

#yiv4333807961 #yiv4333807961 -- _filtered {} _filtered {} _filtered {} 
_filtered {}#yiv4333807961 #yiv4333807961 p.yiv4333807961MsoNormal, 
#yiv4333807961 li.yiv4333807961MsoNormal, #yiv4333807961 
div.yiv4333807961MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv4333807961
 a:link, #yiv4333807961 span.yiv4333807961MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv4333807961 a:visited, #yiv4333807961 
span.yiv4333807961MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv4333807961 p 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv4333807961
 p.yiv4333807961msonormal, #yiv4333807961 li.yiv4333807961msonormal, 
#yiv4333807961 div.yiv4333807961msonormal 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv4333807961
 p.yiv4333807961msochpdefault, #yiv4333807961 li.yiv4333807961msochpdefault, 
#yiv4333807961 div.yiv4333807961msochpdefault 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv4333807961
 span.yiv4333807961msohyperlink {}#yiv4333807961 
span.yiv4333807961msohyperlinkfollowed {}#yiv4333807961 
span.yiv4333807961emailstyle18 {}#yiv4333807961 p.yiv4333807961msonormal1, 
#yiv4333807961 li.yiv4333807961msonormal1, #yiv4333807961 
div.yiv4333807961msonormal1 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv4333807961 
span.yiv4333807961msohyperlink1 
{color:blue;text-decoration:underline;}#yiv4333807961 
span.yiv4333807961msohyperlinkfollowed1 
{color:purple;text-decoration:underline;}#yiv4333807961 
span.yiv4333807961emailstyle181 {color:#1F497D;}#yiv4333807961 
p.yiv4333807961msochpdefault1, #yiv4333807961 li.yiv4333807961msochpdefault1, 
#yiv4333807961 div.yiv4333807961msochpdefault1 
{margin-right:0in;margin-left:0in;font-size:10.0pt;}#yiv4333807961 
span.yiv4333807961EmailStyle28 {color:#1F497D;}#yiv4333807961 
.yiv4333807961MsoChpDefault {} _filtered {}#yiv4333807961 
div.yiv4333807961WordSection1 {}#yiv4333807961 _filtered {} _filtered {} 
_filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} 
_filtered {} _filtered {}#yiv4333807961 ol {margin-bottom:0in;}#yiv4333807961 
ul {margin-bottom:0in;}#yiv4333807961 Correct. The file version resource needs 
to be added.    If you are using an IDE like Visual Studio you can add the 
resource as a project property and, once added, set it either in VS or during 
your make process.    Otherwise, there are plenty of tools available that can 
add the resource and set the value outside the development tool.    Al AB2ZY    
From: Sam W2JDB via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Sent: Sunday, October 04, 2020 4:20 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Sam W2JDB
Subject: Re: [wsjt-devel] Set file version in program resources    Hi Al,    I 
don't believe the file version or product version is carried by the executable. 
Easy way to check that out is just by hovering over the file in Windows 
Explorer. If the data is there, it is displayed. Just tried it and its not 
being displayed.    73, Sam W2JDB       -Original Message-
From: Al Kozakiewicz 
To: WSJT software development 
Sent: Sun, Oct 4, 2020 3:36 pm
Subject: Re: [wsjt-devel] Set file version in program resources Launching WSJT 
is not an issue. It works fine for the many hundreds of users who currently use 
both and N1MM for contesting. The idea is that the ISO language code that 
drives the N1MM localization behavior is what is passed to WSJT, regardless of 
the PC localization settings. If WSJT doesn’t support that language, it starts 
in English, which is fine behavior.   This is not a feature request. No coding 
is required. We merely would like the version information of the Windows .exe 
file filled out during your make process or however you build your solution. I 
can provide you with a freeware tool and instructions to do so.   Best regards, 
  Al AB2ZY   From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, October 04, 2020 11:52 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Set file version in program resources   Al,   it 
seems to me that if you are going to start WSJT-X for the user, btw not sure 
how you are going to do that if it is running on a different host and maybe 
different operating system than Windows, then you must have specific options in 
N1MM Logger+ to allow the user to customize WSJT-X. Surely then the user will 
only request a different UI language for WSJT-X if it happens to not 

Re: [wsjt-devel] Set file version in program resources

[Al Kozakiewicz]

Correct. The file version resource needs to be added.

If you are using an IDE like Visual Studio you can add the resource as a 
project property and, once added, set it either in VS or during your make 
process.

Otherwise, there are plenty of tools available that can add the resource and 
set the value outside the development tool.

Al
AB2ZY

From: Sam W2JDB via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Sent: Sunday, October 04, 2020 4:20 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Sam W2JDB
Subject: Re: [wsjt-devel] Set file version in program resources

Hi Al,

I don't believe the file version or product version is carried by the 
executable.
Easy way to check that out is just by hovering over the file in Windows 
Explorer.
If the data is there, it is displayed. Just tried it and its not being 
displayed.

73,
Sam W2JDB


-Original Message-
From: Al Kozakiewicz 
To: WSJT software development 
Sent: Sun, Oct 4, 2020 3:36 pm
Subject: Re: [wsjt-devel] Set file version in program resources
Launching WSJT is not an issue. It works fine for the many hundreds of users 
who currently use both and N1MM for contesting. The idea is that the ISO 
language code that drives the N1MM localization behavior is what is passed to 
WSJT, regardless of the PC localization settings. If WSJT doesn’t support that 
language, it starts in English, which is fine behavior.

This is not a feature request. No coding is required. We merely would like the 
version information of the Windows .exe file filled out during your make 
process or however you build your solution. I can provide you with a freeware 
tool and instructions to do so.

Best regards,

Al
AB2ZY

From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, October 04, 2020 11:52 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Set file version in program resources

Al,

it seems to me that if you are going to start WSJT-X for the user, btw not sure 
how you are going to do that if it is running on a different host and maybe 
different operating system than Windows, then you must have specific options in 
N1MM Logger+ to allow the user to customize WSJT-X. Surely then the user will 
only request a different UI language for WSJT-X if it happens to not start in 
the one they want, i.e. they will only set the option where it is supported in 
WSJT-X.

We are always going to be reluctant to add features that limit the usage of 
WSJT-X to only one operating system or network configuration, or discourage the 
use of WSJT-X on any of the operating systems supported.

73
Bill
G4WJS.

On 04/10/2020 16:38, Al Kozakiewicz wrote:
On the contrary, it is necessary to support those users who do not wish for 
WSJT to start with the PC’s locale. N1MM is localized and we launch WSJT with 
the same language N1MM is set to, which may not be the same as the PC.

For example, many Japanese users prefer English. Before we made this change, 
N1MM+ would start with English as the language but there was no way to start 
WSJT in any language except Japanese without the use of the –language command.

Al
AB2ZY

From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, October 04, 2020 11:31 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Set file version in program resources

On 04/10/2020 15:56, Al Kozakiewicz wrote:
I’m with the N1MM development team.

We recently added support for the –language= command line token when launching 
WSJT-X. Of course, WSJT  is not backwards compatible, so versions older than 
2.2 error out on launch when appending the command.  I got around the issue by 
checking the last modified date of wsjtx.exe, but this only works as long as 
there is only one version dependence over time. It would be helpful if you set 
the program version as one of the file resources either at build time or after 
the solution is built.

To be clear, the version number needs to be known so the program can launched 
with version specific options. The text in the heartbeat message is of no use 
for this purpose.

Al
AB2ZY
Hi Al,
thanks for subscribing to the list.
There is no need to pass the --language= to WSJT-X to set the GUI 
language, that is done automatically according to the locale set in the 
operating system. There are only really two use cases for using that command 
line option:

  *   When testing and you want to select a different locale from the default 
just for WSJT-X,
  *   or when the user doesn't want the default, usually requiring the en-US 
default.
Seems to me that you don't need to worry about the former, and for the latter 
the user will only choose it is a translated UI is available. So you shouldn't 
need the version of WSJT-X to determine if translation is available.
The WSJT-X version is available in the WSJT-X UDP Message Protocol Heartbeat 
message. I realize that is too late for your requirement, but I don't think the 
requirement is necessary.
73
Bill

Re: [wsjt-devel] Set file version in program resources

[Sam W2JDB via wsjt-devel]

Hi Al,
I don't believe the file version or product version is carried by the 
executable. Easy way to check that out is just by hovering over the file in 
Windows Explorer.If the data is there, it is displayed. Just tried it and its 
not being displayed.
73,

Sam W2JDB


-Original Message-
From: Al Kozakiewicz 
To: WSJT software development 
Sent: Sun, Oct 4, 2020 3:36 pm
Subject: Re: [wsjt-devel] Set file version in program resources

#yiv1291423646 #yiv1291423646 -- _filtered {} _filtered {} _filtered 
{}#yiv1291423646 #yiv1291423646 p.yiv1291423646MsoNormal, #yiv1291423646 
li.yiv1291423646MsoNormal, #yiv1291423646 div.yiv1291423646MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv1291423646
 a:link, #yiv1291423646 span.yiv1291423646MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv1291423646 a:visited, #yiv1291423646 
span.yiv1291423646MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv1291423646 p 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv1291423646
 span.yiv1291423646EmailStyle18 {color:#1F497D;}#yiv1291423646 
.yiv1291423646MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv1291423646 
div.yiv1291423646WordSection1 {}#yiv1291423646 _filtered {} _filtered {} 
_filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} 
_filtered {} _filtered {}#yiv1291423646 ol {margin-bottom:0in;}#yiv1291423646 
ul {margin-bottom:0in;}#yiv1291423646 Launching WSJT is not an issue. It works 
fine for the many hundreds of users who currently use both and N1MM for 
contesting. The idea is that the ISO language code that drives the N1MM 
localization behavior is what is passed to WSJT, regardless of the PC 
localization settings. If WSJT doesn’t support that language, it starts in 
English, which is fine behavior.    This is not a feature request. No coding is 
required. We merely would like the version information of the Windows .exe file 
filled out during your make process or however you build your solution. I can 
provide you with a freeware tool and instructions to do so.    Best regards,    
Al AB2ZY    From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, October 04, 2020 11:52 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Set file version in program resources    Al,    it 
seems to me that if you are going to start WSJT-X for the user, btw not sure 
how you are going to do that if it is running on a different host and maybe 
different operating system than Windows, then you must have specific options in 
N1MM Logger+ to allow the user to customize WSJT-X. Surely then the user will 
only request a different UI language for WSJT-X if it happens to not start in 
the one they want, i.e. they will only set the option where it is supported in 
WSJT-X.    We are always going to be reluctant to add features that limit the 
usage of WSJT-X to only one operating system or network configuration, or 
discourage the use of WSJT-X on any of the operating systems supported.    73
Bill
G4WJS.    On 04/10/2020 16:38, Al Kozakiewicz wrote: 
On the contrary, it is necessary to support those users who do not wish for 
WSJT to start with the PC’s locale. N1MM is localized and we launch WSJT with 
the same language N1MM is set to, which may not be the same as the PC.   For 
example, many Japanese users prefer English. Before we made this change, N1MM+ 
would start with English as the language but there was no way to start WSJT in 
any language except Japanese without the use of the –language command.   Al 
AB2ZY   From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, October 04, 2020 11:31 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Set file version in program resources   On 04/10/2020 
15:56, Al Kozakiewicz wrote: 
I’m with the N1MM development team.   We recently added support for the 
–language= command line token when launching WSJT-X. Of course, WSJT  is not 
backwards compatible, so versions older than 2.2 error out on launch when 
appending the command.  I got around the issue by checking the last modified 
date of wsjtx.exe, but this only works as long as there is only one version 
dependence over time. It would be helpful if you set the program version as one 
of the file resources either at build time or after the solution is built.   To 
be clear, the version number needs to be known so the program can launched with 
version specific options. The text in the heartbeat message is of no use for 
this purpose.   Al AB2ZY 
Hi Al, thanks for subscribing to the list. There is no need to pass the 
--language= to WSJT-X to set the GUI language, that is done 
automatically according to the locale set in the operating system. There are 
only really two use cases for using that command line option:
   - When testing and you want to select a different locale from the default 
just for WSJT-X,
   - or when the user doesn't want the default, usually 

Re: [wsjt-devel] Release Candidate: WSJT-X 2.3.0-rc1 Band hopping issue.

[Bensay 1]

Hi Bill,

Sure, here you will find the WSJT-X settings file : https://we.tl/t-2waVjevjyU

Many thanks for your next clues.

73
Benjamin
F4FPR – AG5HQ

De : Bill Somerville 
Envoyé : mardi 29 septembre 2020 13:07
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] Release Candidate: WSJT-X 2.3.0-rc1 Band hopping issue.

Hi Benjamin,

thanks for the extra details, can you send you WSJT-X settings file please? The 
location of the settings file (WSJT-X.ini) is shown in the User Guide:

https://physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.3.0-rc1.html#_file_locations

73
Bill
G4WJS.

On 29/09/2020 08:59, Bensay 1 wrote:
Dear Bill,

Sure,
Radio is set to
Yeasu FT-991.
I’m on RX only situation for my yesterday test.
I was on rx onto 630m band
Band hopping was set but TX disabled and Tx % set to 0.
After this band hopping was selected but doesn’t seem to be functional.
I for try only push the Tune button and release it, then my band hopping RX 
only was ok;
I can reproduce it easily if I close WSJT-X and then open it again same issue 
until I TX at least once (Tune or TX);
Unusual isn’t it :) ?

73 de Benjamin L / F4FPR / AG5HQ


Le 29 sept. 2020 à 02:47, Bill Somerville 
 a écrit :

On 29/09/2020 00:29, Bill Somerville wrote:
On 29/09/2020 00:11, Bensay 1 wrote:

Dear WSJT-X Devels,

I just upgraded my WSJT-X version up to the 2.3.0-rc1;
But unfortunately the band hopping seems to be defective;
Is this a known issue ?
Rig : FT-991 (Yaesu)
Windows 10 pro Beelink computer.
Cat is working well but Band hopping does not , and WSJT-X doesn’t display 
night / day / sunrise / sunset.

Thanks for your next advice.

73 de Benjamin L / F4FPR - AG5HQ

Hi Benjamin,

thanks for the issue report, I can confirm this is a regression. It will be 
fixed for the next release.

73
Bill
G4WJS.

Hi Benjamin,

I have changed my mind on this issue. I cannot reproduce it. What do you have 
selected for "Settings->Radio->Rig"?

73
Bill
G4WJS.


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Set file version in program resources

[Al Kozakiewicz]

Launching WSJT is not an issue. It works fine for the many hundreds of users 
who currently use both and N1MM for contesting. The idea is that the ISO 
language code that drives the N1MM localization behavior is what is passed to 
WSJT, regardless of the PC localization settings. If WSJT doesn't support that 
language, it starts in English, which is fine behavior.

This is not a feature request. No coding is required. We merely would like the 
version information of the Windows .exe file filled out during your make 
process or however you build your solution. I can provide you with a freeware 
tool and instructions to do so.

Best regards,

Al
AB2ZY

From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, October 04, 2020 11:52 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Set file version in program resources

Al,

it seems to me that if you are going to start WSJT-X for the user, btw not sure 
how you are going to do that if it is running on a different host and maybe 
different operating system than Windows, then you must have specific options in 
N1MM Logger+ to allow the user to customize WSJT-X. Surely then the user will 
only request a different UI language for WSJT-X if it happens to not start in 
the one they want, i.e. they will only set the option where it is supported in 
WSJT-X.

We are always going to be reluctant to add features that limit the usage of 
WSJT-X to only one operating system or network configuration, or discourage the 
use of WSJT-X on any of the operating systems supported.

73
Bill
G4WJS.

On 04/10/2020 16:38, Al Kozakiewicz wrote:
On the contrary, it is necessary to support those users who do not wish for 
WSJT to start with the PC's locale. N1MM is localized and we launch WSJT with 
the same language N1MM is set to, which may not be the same as the PC.

For example, many Japanese users prefer English. Before we made this change, 
N1MM+ would start with English as the language but there was no way to start 
WSJT in any language except Japanese without the use of the -language command.

Al
AB2ZY

From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, October 04, 2020 11:31 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Set file version in program resources

On 04/10/2020 15:56, Al Kozakiewicz wrote:
I'm with the N1MM development team.

We recently added support for the -language= command line token when launching 
WSJT-X. Of course, WSJT  is not backwards compatible, so versions older than 
2.2 error out on launch when appending the command.  I got around the issue by 
checking the last modified date of wsjtx.exe, but this only works as long as 
there is only one version dependence over time. It would be helpful if you set 
the program version as one of the file resources either at build time or after 
the solution is built.

To be clear, the version number needs to be known so the program can launched 
with version specific options. The text in the heartbeat message is of no use 
for this purpose.

Al
AB2ZY

Hi Al,

thanks for subscribing to the list.

There is no need to pass the --language= to WSJT-X to set the GUI 
language, that is done automatically according to the locale set in the 
operating system. There are only really two use cases for using that command 
line option:

  *   When testing and you want to select a different locale from the default 
just for WSJT-X,
  *   or when the user doesn't want the default, usually requiring the en-US 
default.

Seems to me that you don't need to worry about the former, and for the latter 
the user will only choose it is a translated UI is available. So you shouldn't 
need the version of WSJT-X to determine if translation is available.

The WSJT-X version is available in the WSJT-X UDP Message Protocol Heartbeat 
message. I realize that is too late for your requirement, but I don't think the 
requirement is necessary.

73
Bill
G4WJS.


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.3.0-rc1 UI on adding a new configuration

[jan0]

Bill,

 

When I wrote, “delete the storage of the current configuration,” I meant the 
named configuration that was presently being used as the current configuration. 
 Once I have CurrentConfig = UserConfig1, can’t I delete UserConfig1 and keep 
CurrentConfig?  

 

And thanks for the explanation of the configuration reset command – new 
information not otherwise available.  Could we add that to the next 
documentation release?

 

Ed.

 

From: Bill Somerville  
Sent: Sunday, October 4, 2020 12:55 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] 2.3.0-rc1 UI on adding a new configuration

 

Ed,

 

what you describe is simply not possible. WSJT-X has to have a current 
configuration, if you want to delete the current configuration then another 
must become current. If you don't want the current configuration and you don't 
want to switch to another then all you need do is reset the current 
configuration, that will shift all settings to defaults, as if you had 
installed WSJT-X for the first time, with the exception that any other 
configurations you have created will be preserved.

 

73
Bill
G4WJS.

 

On 04/10/2020 17:47, j...@comcast.net   wrote:

Bill,
 
It's not true that, "[i]f you no longer want a configuration then you surely
are going to select a different one."  I delete configurations regularly --
at the end of a DXpedition or contest, for example -- without a desire to
switch to some other configuration at that moment.  It's just housekeeping,
so that the number of saved configurations does not grow without bound.  At
a club station that I visit, due to member turnover, changing interests, and
equipment changes unused configurations are deleted frequently.
 
If I delete a current configuration, I expect the program to delete the
storage of the current configuration and remove the current configuration
name from the pull-down configuration list and the status bar at the bottom
of the main window, but otherwise do nothing detectable to the user -- it's
just a configuration that is no longer selectable, so the user cannot return
to the current configuration once he leaves it.  If I delete the last
remaining configuration, I would expect the program to operate as if the
configuration feature did not exist -- i.e., it would stay with its present
settings, but all future settings changes would have to be entered manually,
as there would be no user-accessible memory of, well, prior settings
configurations, until a new configuration was saved.  
 
73,
 
Ed N4II
 
-Original Message-
From: Bill Somerville    
Sent: Sunday, October 4, 2020 9:50 AM
To: wsjt-devel@lists.sourceforge.net  
Subject: Re: [wsjt-devel] 2.3.0-rc1 UI on adding a new configuration
 
On 04/10/2020 11:23, Alan Groups wrote:

One other thing - would be more intuitive if one could delete a 
configuration without having to open another one first!
 
Alan G0TLK

Hi Alan,
 
I'm not sure I follow this request. If you no longer want a configuration
then you surely are going to select a different one, OTOH if you want to
reset a configuration to defaults you can do that whether it is the current
one or not. If we allowed deleting the current configuration then which
configuration should be substituted? What should the common edge case of
only having one configuration and deleting it do?
 
73
Bill
G4WJS.

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.3.0-rc1 UI on adding a new configuration

[Bill Somerville]

Ed,

what you describe is simply not possible. WSJT-X has to have a current 
configuration, if you want to delete the current configuration then 
another must become current. If you don't want the current configuration 
and you don't want to switch to another then all you need do is reset 
the current configuration, that will shift all settings to defaults, as 
if you had installed WSJT-X for the first time, with the exception that 
any other configurations you have created will be preserved.


73
Bill
G4WJS.

On 04/10/2020 17:47, j...@comcast.net wrote:

Bill,

It's not true that, "[i]f you no longer want a configuration then you surely
are going to select a different one."  I delete configurations regularly --
at the end of a DXpedition or contest, for example -- without a desire to
switch to some other configuration at that moment.  It's just housekeeping,
so that the number of saved configurations does not grow without bound.  At
a club station that I visit, due to member turnover, changing interests, and
equipment changes unused configurations are deleted frequently.

If I delete a current configuration, I expect the program to delete the
storage of the current configuration and remove the current configuration
name from the pull-down configuration list and the status bar at the bottom
of the main window, but otherwise do nothing detectable to the user -- it's
just a configuration that is no longer selectable, so the user cannot return
to the current configuration once he leaves it.  If I delete the last
remaining configuration, I would expect the program to operate as if the
configuration feature did not exist -- i.e., it would stay with its present
settings, but all future settings changes would have to be entered manually,
as there would be no user-accessible memory of, well, prior settings
configurations, until a new configuration was saved.

73,

Ed N4II

-Original Message-
From: Bill Somerville  
Sent: Sunday, October 4, 2020 9:50 AM

To:wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] 2.3.0-rc1 UI on adding a new configuration

On 04/10/2020 11:23, Alan Groups wrote:

One other thing - would be more intuitive if one could delete a
configuration without having to open another one first!

Alan G0TLK

Hi Alan,

I'm not sure I follow this request. If you no longer want a configuration
then you surely are going to select a different one, OTOH if you want to
reset a configuration to defaults you can do that whether it is the current
one or not. If we allowed deleting the current configuration then which
configuration should be substituted? What should the common edge case of
only having one configuration and deleting it do?

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.3.0-rc1 UI on adding a new configuration

[jan0]

Bill,

It's not true that, "[i]f you no longer want a configuration then you surely
are going to select a different one."  I delete configurations regularly --
at the end of a DXpedition or contest, for example -- without a desire to
switch to some other configuration at that moment.  It's just housekeeping,
so that the number of saved configurations does not grow without bound.  At
a club station that I visit, due to member turnover, changing interests, and
equipment changes unused configurations are deleted frequently.

If I delete a current configuration, I expect the program to delete the
storage of the current configuration and remove the current configuration
name from the pull-down configuration list and the status bar at the bottom
of the main window, but otherwise do nothing detectable to the user -- it's
just a configuration that is no longer selectable, so the user cannot return
to the current configuration once he leaves it.  If I delete the last
remaining configuration, I would expect the program to operate as if the
configuration feature did not exist -- i.e., it would stay with its present
settings, but all future settings changes would have to be entered manually,
as there would be no user-accessible memory of, well, prior settings
configurations, until a new configuration was saved.  

73,

Ed N4II

-Original Message-
From: Bill Somerville  
Sent: Sunday, October 4, 2020 9:50 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] 2.3.0-rc1 UI on adding a new configuration

On 04/10/2020 11:23, Alan Groups wrote:
> One other thing - would be more intuitive if one could delete a 
> configuration without having to open another one first!
>
> Alan G0TLK

Hi Alan,

I'm not sure I follow this request. If you no longer want a configuration
then you surely are going to select a different one, OTOH if you want to
reset a configuration to defaults you can do that whether it is the current
one or not. If we allowed deleting the current configuration then which
configuration should be substituted? What should the common edge case of
only having one configuration and deleting it do?

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.3.0-rc1 UI on adding a new configuration

[Alan]

If only one then obviously no point in being able to delete it, but on the 
other hand could be useful as a factory reset?


In my testing I tried a new configuration that didn't work (unsupported 
SDR) so wanted to delete it.


The need to select another one first wasn't obvious - I had to look it up 
to find out.


Alan G0TLK, sent from my mobile device
On 4 October 2020 14:52:34 Bill Somerville  wrote:


On 04/10/2020 11:23, Alan Groups wrote:

One other thing - would be more intuitive if one could delete a
configuration without having to open another one first!

Alan G0TLK


Hi Alan,

I'm not sure I follow this request. If you no longer want a
configuration then you surely are going to select a different one, OTOH
if you want to reset a configuration to defaults you can do that whether
it is the current one or not. If we allowed deleting the current
configuration then which configuration should be substituted? What
should the common edge case of only having one configuration and
deleting it do?

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Set file version in program resources

[Bill Somerville]

Al,

it seems to me that if you are going to start WSJT-X for the user, btw 
not sure how you are going to do that if it is running on a different 
host and maybe different operating system than Windows, then you must 
have specific options in N1MM Logger+ to allow the user to customize 
WSJT-X. Surely then the user will only request a different UI language 
for WSJT-X if it happens to not start in the one they want, i.e. they 
will only set the option where it is supported in WSJT-X.


We are always going to be reluctant to add features that limit the usage 
of WSJT-X to only one operating system or network configuration, or 
discourage the use of WSJT-X on any of the operating systems supported.


73
Bill
G4WJS.

On 04/10/2020 16:38, Al Kozakiewicz wrote:


On the contrary, it is necessary to support those users who do not 
wish for WSJT to start with the PC’s locale. N1MM is localized and we 
launch WSJT with the same language N1MM is set to, which may not be 
the same as the PC.


For example, many Japanese users prefer English. Before we made this 
change, N1MM+ would start with English as the language but there was 
no way to start WSJT in any language except Japanese without the use 
of the –language command.


Al

AB2ZY

*From:*Bill Somerville [mailto:g4...@classdesign.com]
*Sent:* Sunday, October 04, 2020 11:31 AM
*To:* wsjt-devel@lists.sourceforge.net
*Subject:* Re: [wsjt-devel] Set file version in program resources

On 04/10/2020 15:56, Al Kozakiewicz wrote:

I’m with the N1MM development team.

We recently added support for the –language= command line token
when launching WSJT-X. Of course, WSJT  is not backwards
compatible, so versions older than 2.2 error out on launch when
appending the command.  I got around the issue by checking the
last modified date of wsjtx.exe, but this only works as long as
there is only one version dependence over time. It would be
helpful if you set the program version as one of the file
resources either at build time or after the solution is built.

To be clear, the version number needs to be known so the program
can launched with version specific options. The text in the
heartbeat message is of no use for this purpose.

Al

AB2ZY

Hi Al,

thanks for subscribing to the list.

There is no need to pass the --language= to WSJT-X to set 
the GUI language, that is done automatically according to the locale 
set in the operating system. There are only really two use cases for 
using that command line option:


  * When testing and you want to select a different locale from the
default just for WSJT-X,
  * or when the user doesn't want the default, usually requiring the
en-US default.

Seems to me that you don't need to worry about the former, and for the 
latter the user will only choose it is a translated UI is available. 
So you shouldn't need the version of WSJT-X to determine if 
translation is available.


The WSJT-X version is available in the WSJT-X UDP Message Protocol 
Heartbeat message. I realize that is too late for your requirement, 
but I don't think the requirement is necessary.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Set file version in program resources

[Al Kozakiewicz]

On the contrary, it is necessary to support those users who do not wish for 
WSJT to start with the PC's locale. N1MM is localized and we launch WSJT with 
the same language N1MM is set to, which may not be the same as the PC.

For example, many Japanese users prefer English. Before we made this change, 
N1MM+ would start with English as the language but there was no way to start 
WSJT in any language except Japanese without the use of the -language command.

Al
AB2ZY

From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, October 04, 2020 11:31 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Set file version in program resources

On 04/10/2020 15:56, Al Kozakiewicz wrote:
I'm with the N1MM development team.

We recently added support for the -language= command line token when launching 
WSJT-X. Of course, WSJT  is not backwards compatible, so versions older than 
2.2 error out on launch when appending the command.  I got around the issue by 
checking the last modified date of wsjtx.exe, but this only works as long as 
there is only one version dependence over time. It would be helpful if you set 
the program version as one of the file resources either at build time or after 
the solution is built.

To be clear, the version number needs to be known so the program can launched 
with version specific options. The text in the heartbeat message is of no use 
for this purpose.

Al
AB2ZY

Hi Al,

thanks for subscribing to the list.

There is no need to pass the --language= to WSJT-X to set the GUI 
language, that is done automatically according to the locale set in the 
operating system. There are only really two use cases for using that command 
line option:

  *   When testing and you want to select a different locale from the default 
just for WSJT-X,
  *   or when the user doesn't want the default, usually requiring the en-US 
default.

Seems to me that you don't need to worry about the former, and for the latter 
the user will only choose it is a translated UI is available. So you shouldn't 
need the version of WSJT-X to determine if translation is available.

The WSJT-X version is available in the WSJT-X UDP Message Protocol Heartbeat 
message. I realize that is too late for your requirement, but I don't think the 
requirement is necessary.

73
Bill
G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Set file version in program resources

[Bill Somerville]

On 04/10/2020 15:56, Al Kozakiewicz wrote:


I’m with the N1MM development team.

We recently added support for the –language= command line token when 
launching WSJT-X. Of course, WSJT  is not backwards compatible, so 
versions older than 2.2 error out on launch when appending the 
command.  I got around the issue by checking the last modified date of 
wsjtx.exe, but this only works as long as there is only one version 
dependence over time. It would be helpful if you set the program 
version as one of the file resources either at build time or after the 
solution is built.


To be clear, the version number needs to be known so the program can 
launched with version specific options. The text in the heartbeat 
message is of no use for this purpose.


Al

AB2ZY


Hi Al,

thanks for subscribing to the list.

There is no need to pass the --language= to WSJT-X to set the 
GUI language, that is done automatically according to the locale set in 
the operating system. There are only really two use cases for using that 
command line option:


 * When testing and you want to select a different locale from the
   default just for WSJT-X,
 * or when the user doesn't want the default, usually requiring the
   en-US default.

Seems to me that you don't need to worry about the former, and for the 
latter the user will only choose it is a translated UI is available. So 
you shouldn't need the version of WSJT-X to determine if translation is 
available.


The WSJT-X version is available in the WSJT-X UDP Message Protocol 
Heartbeat message. I realize that is too late for your requirement, but 
I don't think the requirement is necessary.


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Set file version in program resources

[Al Kozakiewicz]

I'm with the N1MM development team.

We recently added support for the -language= command line token when launching 
WSJT-X. Of course, WSJT  is not backwards compatible, so versions older than 
2.2 error out on launch when appending the command.  I got around the issue by 
checking the last modified date of wsjtx.exe, but this only works as long as 
there is only one version dependence over time. It would be helpful if you set 
the program version as one of the file resources either at build time or after 
the solution is built.

To be clear, the version number needs to be known so the program can launched 
with version specific options. The text in the heartbeat message is of no use 
for this purpose.

Al
AB2ZY

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.3.0-rc1 UI on adding a new configuration

[Bill Somerville]

On 04/10/2020 11:23, Alan Groups wrote:
One other thing - would be more intuitive if one could delete a 
configuration without having to open another one first!


Alan G0TLK


Hi Alan,

I'm not sure I follow this request. If you no longer want a 
configuration then you surely are going to select a different one, OTOH 
if you want to reset a configuration to defaults you can do that whether 
it is the current one or not. If we allowed deleting the current 
configuration then which configuration should be substituted? What 
should the common edge case of only having one configuration and 
deleting it do?


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.3.0-rc1 UI on adding a new configuration

[Alan Groups]

Hi, testing this by adding a new configuration for a Funcube SDR as my 
main rig doesn't cover these low bands.


On changing between configurations once the new one was set WSJT-X 
restarted but when it did the main screen went top left of my monitor, 
with most of the title block off screen, and overlaid the wide graph.  
The wide graph title block was also only partly shown, and both windows 
were also a little too far to the left and with a little bit off screen.


Both windows could be dragged into place so all visible, and then the 
placement was remembered for both windows, in both configurations.  
Therefore a once only issue.


One other thing - would be more intuitive if one could delete a 
configuration without having to open another one first!


Alan G0TLK




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel