Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Blocking Keys in Virtual Desktop
I'm testing my macros on an ASP over the internet with QuickBooks, and, while the macros run pretty much as they do on my desktop, the "BlockInput 1" does not Block my keys sent over the Microsoft Virtual Desktop system, which is important for the function of the macros. Any thoughts on achiving the blocking effect in this configuration?

Thanks, Craig
Thinking about it further, the following comes to mind:

I realize that I will need to have a macro running on my desktop in addition to my primary macro on the server. The server based macro, instead of issuing BlockInput (1 or 0) must, instead, signal the desktop macro to issue the BlockInput commands on the desktop.

I can think of one way to do that: When it is requesting the desktop to block input, the server based macro can put a small window in a pre-defined, out of the way location that says "Input Blocked". It later removes that window to signal the desktop macro to unblock the keyboard/mouse again.

Since the Windows Virtual Desktop is not passing Window IDs, classes or any other info, it would appear that I am going to have to control the desktop Macro solely through pixel color changes on the server which will show up in the in the signalling "Input Blocked" window.

If no issues arise from this I suppose it is a good solution. But if there is a more efficient way for the server based macro to communicate with my desktop based macro via Windows Remote Desktop, I'd love to know about it.

BlockInput works if you use Windows XP Remote Desktop. I tested it with two XP Pro computers on local network.

QM 2.1.6 allows to run macros on other computers. For example, your server macro could launch a desktop macro that blocks input. QM 2.1.6 beta will be available this week.
I'm not sure why mine is not blocking, then. Is there an option other than 1 that should follow BlockInput if I want it to block input from my desktop to the remote server? The macro works perfectly on my desktop only, and it works perfectly on the remote server with that one exception that input is not blocked when I need it.

I've checked that all the options on the QM server installation are the same as those on the desktop installation. The only difference I've noted is that I do not see the tray icon anywhere on the Virtual Desktop. I don't know if that is important or means anything but the macro runs.

When you work with server computer directly (not from another computer), BlockInput does not work too?
I do not know. The server is 1000 Km away from me, and I can only log on through the web.

I am developing a system with an ASP who will host QuickBooks and QM for me. When this is working, I will be private labeling my own hosting service with QM enhancements to QuickBooks. The ASP will require a license for each user of each hosted software, so I'm expecting to sell many copies of your software. It will give me great pleasure to do so since you have been so helpful. It's definitely the future of small business computing. They will host any software and so, I can keep my laptop as a thin client and work from anywhere in the world while the ASP does the work of maintaining my accessibility.

If you wish to log in and see, let me know and I'll send you the information. This is the last hurdle before I can start offering my first product to more than one client.
I will not solve this problem with BlockInput. There is an alternative:
OK, I added "dll# user32 BlockInput fBlockIt" to my macro before the first call of BlockInput...and it worked!

Can you think of any reason for me to need to renew the statement, either because a new macro is called from this one, or because because something about "user32" changes. I don't know what user32 refers to but I just want to anticipate issues in my planned for multiple Virtual Desktop/user environment.

Thanks again Gintaras.
My first thought was that function init did not run, or it failed to compile. But it would cause "unknown identifier" error when BlockInput is called. Now I don't know what is the reason. If BlockInput works when declared later, it is ok. But I afraid that other dll functions also may not work.
I'm sorry, Gintaras, I was telling you that it worked, that there is no problem. Because I do not understand the nature of "user32" or DLL# I was just looking ahead to see if you could anticipate any issues for this when I have more than one issue. Again, thanks it DOES work!


Forum Jump:

Users browsing this thread: 1 Guest(s)