Hi Bill,
Well, I feel like an idiot. All my problems were self induced, nothing
to do with a new Qt version.
I had been running some tests earlier to replicate a problem a user was
having which involved setting wsjtx to run as administrator. I had
neglected to remove that setting. A real rookie mistake. Why it never
occured to me that was the problem, I don't know. I have had to advise
many users over the years to not set wsjtx or jt65-hf to Run as admin as
the Vista/Win7/Win8 security model will prevent normal privileged
process (JTAlert) from interacting with elevated processes (wsjtx) which
produces the results I was seeing.
The problems I was experiencing were all consistent with what I had seen
many times in the past. I just assumed it was broken due to the new
1.4.0 version.
I hope you didn't spend too much time developing the WM_APP message
solution. My old methods using standard commands, ShowWindow(),
MoveWindow() and SetWindowPos() are working and I will continue to use
them, rather than using different methods based on wsjtx version.
Thanks again for your time on this.
de Laurie, VK3AMA
------------------------------------------------------------------------
On 7/04/2014 9:41 PM, Bill Somerville wrote:
On 07/04/2014 01:54, Laurie VK3AMA wrote:
Hi Bill,
Hi Laurie,
Sounds like it is the new Qt code. I have no experience with Qt but
it has been the root of some of the issues I have had to overcome for
JTAlert.
I am getting the window handle by enumerating the running wsjtx
processes. I know I am using the correct handle as the window
minimize/restore messages sent via SendMessage are working. The
window positioning is failing so at this time, JTAlert will follow
the wsjtx window, but wsjtx will not follow JTAlert while docked. I
have also confirmed the hWnd is correct using a windows inspection tool.
OK.
I think the problem is that Qt has a layout manager that you are going
to be in conflict with if you call raw WIndows API functions or inject
standard Windows messages.
Can you list the actions and arguments that you need for JTAlert (and
JTMacros) to work. I can probably provide a quick hack with some
custom WM_APP messages for now. I can easily filter these messages and
call the appropriate Qt methods for you.
I think a non-proprietary portable solution should be put in place
eventually.
de Laurie, VK3AMA
73
Bill
G4WJS.
------------------------------------------------------------------------
On 7/04/2014 10:37 AM, Bill Somerville wrote:
On 07/04/2014 01:19, Laurie VK3AMA wrote:
Hi Laurie,
I have been extending JTAlert to support the new 1.4 multi-instance
functionality.
JTAlert docking is now broken with 1.4. Standard api commands,
ShowWindow(), MoveWindow() and SetWindowPos() sent by JTAlert to
the wsjtx window are being ignored.
I have been able to workaround the loss of ShowWindow() for
minimising and restoring the wsjtx window by executing an
appropriate SendMessage() command but am now struggling with wsjtx
window positioning so thought I would post a message here while I
take a break from my tests.
Is something in the 1.4 code dropping the messages sent by these
commands?
All those messages are handled by the default Qt widget code, we
don't filter those messages at all. The only messages we handle
directly are a few function and control keys. I don't think anything
has changed there.
It is probably the Qt code that has changed. We are building (at
least I did in the version I sent you) with Qt 5.2.1 whereas it was
probably 5.1 in the last public release.
How are you getting the window handle Laurie?
de Laurie, VK3AMA
73
Bill
G4WJS.
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
