Re: Issue with @user32.FindWindowA and XPA

Steven Blank


That's how it was working, yes.


On 11/12/2020 3:52 PM, sherman levine wrote:
Would this sequence work ?
1. Calculate permanent title (e.g. MyApplication_MyWorkstationName)
2. Look for existing permanent title (with @User32.FindWindowA)
3. If permanent title exists already,
go there (@user32.ShowWindow) and raise exit system here
rename myself permanent title

On 11/12/2020 6:36 PM, Steven Blank wrote:

I've been playing with this in xpa3 and find that the behavior has definitely changed with regard to the main window caption.

First off, in xpa3, the Application Properties dialog (Ctrl+Shift+P) no longer has Caption or Icon properties, apparently because the Main program's Form name is what's being displayed, not the MDI window's name.

On the one hand, this seed-change makes changing the main form's caption dynamically, at runtime, drop dead simple: reference a variable in the Form name property's Expression and then update the referenced variable as desired. Works great.

On the other hand, this also renders the technique to locate another instance useless, at least as is, so it's back to the drawing board for, possibly, a whole new approach.


I'll continue to futz with it and, if I can figure it out, I'll share it with you.

Steven G. Blank
SGBlank Consulting

On 11/12/2020 2:23 PM, Steven Blank wrote:

In your call to user32.FindWindowA, the second argument ('') is the class name of the window you're attempting to find and it appears that you may have hard coded this in your application. If so, then my first guess would be that the hard-coded class name is still that of the prior version (uniPaaS) and not the new version (xpa) and my second guess would be that it's just incorrect.

In my Instance Manager, I make two preceding calls to user32.GetParent and user32.GetClassName to obtain the runtime window's class name dynamically.


Steven G. Blank
SGBlank Consulting


On 11/12/2020 1:03 PM, Graham White wrote:



We have some logic in our XPA3.3 application that upon starting checks to see if there is another instance of the application running it will close the one that has just been launched, however, this seems to have stopped working and I am not sure why or when.  Here is our scenario..


We have 2 databases one for New Zealand and one for Australia.  We the user starts our menu application they select which country, the logical name pointers to the location of the database are set and the application is launched perfect.  They can then launch another one but can only go into the other country if they try to go into the same country the system closes the window and exits.  How we have done this is by us changing the window title to the country name and checking if there is another window open with the same name.  This has worked but at some point (new server, hardware windows updates??) it has stopped.


The code we use is as follows…


If CtxGetName()='Main'

                Invoke UDP @user32.FindWindowA with Arguments – ‘ AA4’, '', 'Instance Manager', virtual ‘hWndThis’ N10

                Invoke UDP @user32.FindWindowA with Arguments – ‘ AA4’, ' r14_ad1', 'This_Country_Name', virtual ‘hWndThat’ N10

                                If hWndThat<>0 and hWndThis<> hWndThat

                                                Invoke UDP @user32.ShowWindow with Arguments - '440', hWndThat,3

                                Block End

Block End


I am not 100% sure of exactly why/how it does/does not work or in fact if it’s the best way of doing it.  I would appreciate any assistance if figuring out why it doesn’t work or a better way of doing it.





Graham White
Software Developer
EC Credit Control |


IMPORTANT NOTICE: This e-mail message and any attachments are confidential to EC Credit Control and subject to legal privilege (which is not waived or 

lost by mistaken delivery). If you have received this e-mail in error, please advise the sender immediately and destroy the message and any attachments.  

If you are not the intended recipient you are notified that any use, distribution, amendment, copying or any action taken or omitted to be taken in reliance of 

this message or attachments is prohibited. EC Credit Control collects personal information to provide and market our services (see our privacy policy at: – - for more information about use, disclosure and access). 

EC Credit Control’s liability in connection with transmitting, unauthorised access to, or viruses in this message and its attachments is limited to resupply of 

any affected message or attachments.

Join to automatically receive all group messages.