I have noticed that when operating in Split mode, double-clicking on a
line of decoded text causes a momentary change of VFO A frequency,
whenever the final result will also change the frequency of VFO B.
Yes, at the end VFO A is reset back where it should be; but why is it
changed, at all?
Greg --
SVN revisions 4425 and 4426 break everything here.
I think all that's needed is
SET LIBRARY_PATH=
in jtsdk-qtenv.bat, and possibly also in jtsdk-pyenv.bat. Don't put
LIBRARY_PATH into PATH... they're two different things. You don't use
LIBRARY_PATH anywhere in your scripts,
Hi Bill,
On 10/1/2014 18:35, Bill Somerville wrote:
snip
So for the Debug builds, are you saying we don't need to copy the
runtime .dll's over too the install\bin directory ?
Yes, that's the way it works for me.
Yuck! I hate Windows. I've just checked using the dependency walker and
it
RR, 4427 is OK.
But if LIBRARY_PATH defined to be a NULL string, why include it in PATH
at all?
-- Joe
On 10/1/2014 2:40 PM, KI7MT wrote:
Hi Joe,
Yes, it did here too. Had to move the %LIBRARY_PATH% to the end of the
%PATH%
Should be ok now, I just built WSPR and WSJT-X
73's
i Joe, Bill,
I've updated the jtsdk-cmake.bat file so it *does not copy* files over
to install\Debug\bin, rather, it sets paths to GCC, FFTW, QT5 and Hamlib
Dir's.
I wasn't sure if we needed hamlib3\minge32\{bin,lib} or not so I added
them nonetheless. If not, we can take that back out.
It's
On 01/10/2014 20:43, KI7MT wrote:
i Joe, Bill,
Hi Greg,
I've updated the jtsdk-cmake.bat file so it *does not copy* files over
to install\Debug\bin, rather, it sets paths to GCC, FFTW, QT5 and Hamlib
Dir's.
I wasn't sure if we needed hamlib3\minge32\{bin,lib} or not so I added
them
Hi Bill,
I have internet issues something chronic at the moment. T-Bird said this
email failed to deliver like 5 times, so if you get multiples of it,
apologies for that :-)
I got your other mail about plugins as well. The next update can take
them out if not needed.
On 10/1/2014 19:48, Bill
I normally run 7 instances of wsjtx simultaneously under W7 64-bit.
Each instance of wsjtx (and fldigi, and 2*hdsdr) runs in a separate
Finestra workspace.
The new 1.40-rc2 won't stay in a Finestra workspace,
and instead insists on being on top no matter which
workspace is selected.
This isn't
On 02/10/2014 00:36, Josh Rovero wrote:
Hi Josh,
I normally run 7 instances of wsjtx simultaneously under W7 64-bit.
Each instance of wsjtx (and fldigi, and 2*hdsdr) runs in a separate
Finestra workspace.
The new 1.40-rc2 won't stay in a Finestra workspace,
and instead insists on being on
Hi All,
as I am addressing several issues forthcoming from Beta users, I have
checked in a file called issue log.txt into the wsjtx-1.4 branch. Feel
free to update if you are working on other issues or can add details to
current outstanding issues.
73
Bill
G4WJS.
Original Message
Subject:[wsjtgroup] Rig control error - wsjtx v1/4
Date: Wed, 1 Oct 2014 21:26:43 -0400
From: Peter Pauly ppa...@gmail.com [wsjtgroup]
wsjtgroup-nore...@yahoogroups.com
Reply-To: Peter Pauly ppa...@gmail.com
To: wsjt
Forwarded Message
Subject:Re: [wsjtgroup] Rig control error - wsjtx v1/4
Date: Wed, 1 Oct 2014 22:01:56 -0400
From: 'Rudy Benner' r...@vianet.ca [wsjtgroup]
wsjtgroup-nore...@yahoogroups.com
Reply-To: Rudy Benner r...@vianet.ca
To: wsjt
12 matches
Mail list logo
