VB - control pointer in other app
Discussion
I have a bit of VB code (a DLL) that is called from another program and basically queries stock levels against a database. Whilst this is going on, the other program just sits there with the mouse pointer set to a normal pointer. How can I get the mouse pointer in the originating app to set to hourglass whilst my DLL does its stuff.
Basic process I want is:
App1 sends basket contents to DLL
DLL sets pointer for App1 to hourglass
DLL figures out stock
DLL passes stock back to App1
DLL sets pointer for App1 back to normal
Cheers!
Basic process I want is:
App1 sends basket contents to DLL
DLL sets pointer for App1 to hourglass
DLL figures out stock
DLL passes stock back to App1
DLL sets pointer for App1 back to normal
Cheers!
Actually it's a little more complicated than that...
There is another DLL in between the App and the VB DLL. The intermediate DLL is written in C++.
The reason for the C++ DLL is because the app is designed to integrate with it. We are writing the rest of the code in VB because we don't really do C++.
The hourglass thing could easily be done in the C++ DLL if we knew how to do it, and yes that DLL is in the same thread as the app.
There is another DLL in between the App and the VB DLL. The intermediate DLL is written in C++.
The reason for the C++ DLL is because the app is designed to integrate with it. We are writing the rest of the code in VB because we don't really do C++.
The hourglass thing could easily be done in the C++ DLL if we knew how to do it, and yes that DLL is in the same thread as the app.
As far as I can make out from your post, the facts are thus:
(a) The code you are running is in a DLL (MyDll.dll, lets say).
(b) Your application (App1) makes a call to MyDll to do *something*.
(c) You want App1 to display an hourglass whilst MyDll is busy.
(d) You want App1 to revert to the default cursor when MyDll has finished its work.
Therefore, what's wrong with App1 setting its own cursor to an hourglass, making the call to MyDll and then resetting the cursor once the call has completed?
Unless there's something you're not telling us, I can't see where the problem is
{edited to add:}
OK, you've explained a bit further whilst I was typing.
Still don't see the problem, though. App1 sets the hourglass, makes a call to MyCppDll which in turn calls MyVbDll, eventually returning to MyCppDll and then to App1, which then resets the cursor.
>> Edited by pdV6 on Friday 11th February 11:07
(a) The code you are running is in a DLL (MyDll.dll, lets say).
(b) Your application (App1) makes a call to MyDll to do *something*.
(c) You want App1 to display an hourglass whilst MyDll is busy.
(d) You want App1 to revert to the default cursor when MyDll has finished its work.
Therefore, what's wrong with App1 setting its own cursor to an hourglass, making the call to MyDll and then resetting the cursor once the call has completed?
Unless there's something you're not telling us, I can't see where the problem is
{edited to add:}
OK, you've explained a bit further whilst I was typing.
Still don't see the problem, though. App1 sets the hourglass, makes a call to MyCppDll which in turn calls MyVbDll, eventually returning to MyCppDll and then to App1, which then resets the cursor.
>> Edited by pdV6 on Friday 11th February 11:07
Oh hang on a minute. Are you saying that the code in App1 is outside of your control?
If this is the case, you might need to do a bit of funky WinAPI programming to find out the hWnd of App1's window and then its probably possible to mess with the cursor via some more WinAPI shenannigans.
If this is the case, you might need to do a bit of funky WinAPI programming to find out the hWnd of App1's window and then its probably possible to mess with the cursor via some more WinAPI shenannigans.
pdV6 said:
Therefore, what's wrong with App1 setting its own cursor to an hourglass, making the call to MyDll and then resetting the cursor once the call has completed?
If only we wrote App1 !
It's a third party app which we have no control over (in terms of source code) and it interfaces to the outside world through this C DLL (amongst other things but we can't use the other things in this case) but it has no API method via the DLL to change its hourglass.pdV6 said:There is a WinAPI call, RegisterWindowsMessage that creates a unique windows message from a known string. This is then used as a unique means of communication between two systems that know the known string. The message allows for the passing of a UINT, so you could use a pointer to other memory (not recommended as you'd have to manage the memory space) or an integer as a flag to pass what you want to the application.
Oh hang on a minute. Are you saying that the code in App1 is outside of your control?
If this is the case, you might need to do a bit of funky WinAPI programming to find out the hWnd of App1's window and then its probably possible to mess with the cursor via some more WinAPI shenannigans.
Does this make any sense?
Its been a long while since I used this for communications between two application, but I used it to/from VB without problems.
catretriever said:
I can't figure out why you have to fiddle with the cursor of the 3rd party DLL. Surely it's the app that calls' the DLL (i.e the one you are writing) that you need to change the cursor for?
Think its the DLL that he's writing, being called by a 3rd party app by way of another DLL. In my book, the "fault" is in the App itself and the DLL is trying to work around it. Seems mad to me, but hey!
Plotloss said:
Thats what I thought and as its in the same thread that should be a go-er
If it wasnt I could see that it would just set it, call it and then unset it which would be useless.
I know what you mean, but in VB setting Screen.Mousepointer only applies to the windows "owned" by the vb app and not the "screen" as such.
I assume that mm's vb dll is simply doing some data processing with no user interaction to speak of, so the user is left staring at the main application's window(s) with a "live" pointer rather than an hourglass.
I still think the main App is where the change needs to be made.
pdV6 said:
I assume that mm's vb dll is simply doing some data processing with no user interaction to speak of, so the user is left staring at the main application's window(s) with a "live" pointer rather than an hourglass.
I still think the main App is where the change needs to be made.
Absolutely right.
pdV6 said:
To me it sounds as though you're trying to code around deficiencies in the other application. I'm sure there's some way to force what you want, but I'd be tempted to pass the buck back to whoever controls App1's development...
Believe me, this is just the tip of the iceberg deficiency-wise!
Thanks for the advice everyone!
pdV6 said:Sorry, my post came after yours, as I needed a slight memory job!
Stuff
Sounds good, but if its possible to get some coding done in the other app, surely all they'd need to do is set & unset the cursor at the appropriate moment with no need to get any more complex than that!
Does the visual application have a constant window title (or failing that a window class name, although I think they are fixed for VB, can't recall), in which case you can enumerate the available windows or use FindWindow, which will find the hWnd, use SetCursor and Bob's your API call.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff