I have a program that has the option to create a restore point...
My problem is that when you click on it to do so, the program just locks up until it's finished creating the restore point.
I have put a seperate form on the program and it has a Marquee Progress Bar Control which I downloaded, so the idea is...
User clicks "Create Restore Point"
frmRestore.show
Marquee Progress Bar goes on and on while the restore point is created
Restore point is done
frmRestore.hide
The thing is, when you click create restore point, the form shows and the program just locks up, onces the restore point is created the form hides again.
Could this problem be solved with a Background worker? To be honest I'm not completely sure what it does, I mucked around with the controls but can't seem to find anything useful.
Thanks
You need to put the restore procedure in separate thread. If your program is not multi-threaded then it will work linear and lock until it will finish the task it is doing.
The program is locked up because you are doing something intensive on the main thread.
It goes like this in a GUI application:
// do some stuff
// respond to system and redraw gui
// do some stuff
// respond to system and redraw gui
And when you block "// do some stuff" the program won't be able to respond and redraw the gui untill do some stuff is done.
What you need to do is either use a secondary thread or using a background worker like you said. A thread is like, you can do stuff in it without blocking the system or the GUI
hope this helps
I've never seriously used VB, but I think the same concepts apply to Qt (begin rant about Qt being better here).
I'm not sure if VB uses a GUI thread or just one unified one, but I think your problem is that the GUI thread is performing long non-gui operations which cause it to "lock". When it "locks", the program is waiting for the tasks to finish, and hence not letting you interact with it.
Use a separate thread...
Related
I am writing a program (in Microsoft Visual Basic) to control a remote instrument (an XY axis microscope stage). As an example, the user must initially calibrate the stage by clicking a GUI button. It takes some time to accomplish the calibration process and I do not want to freeze the main GUI, so I execute the call on a background thread, as follows:
Call New Thread(AddressOf CALIBRATE_STAGE) With {.IsBackground = True}.Start()
So that works well, but we can imagine that for some reason, the user might need to halt the calibration before it is completed. The halt command must originate from a button on the GUI but it cannot be run from the main thread, or a HUGE instability results. (Basically, a program crash, probably because the sub thread was incorrectly managed. The only fix is to completely reboot the computer.)
I think what I need to do is something like this pseudo-code:
Press HALT button on GUI
Execute the STAGE HALT command on the same sub-thread where the CALIBRATE_STAGE command was launched
Once the stage is halted, properly abort the sub thread
Trouble is, I do not know how to do acquire the specific sub-thread on which CALIBRATE_STAGE is running. I do know its ThreadID, but given that integer, how do I launch a new process on that thread? Does anyone have some ideas?
Or maybe someone knows this idea of mine will not work and has a better solution?
I'm look for code which can help me accomplish what the title suggests.
I want this because I have an issue with a program which is quite buggy (it's a game), and if It freezes, and results in a black screen. Even after using Shift+Ctrl+Esc, Ctrl+Alt+Del, Alt+F4 and the rest of them, I acn't seem to end the program. So I thought that a KeyPress event would work, as it doesn't require me to use the UI in any way.
However, I've never used VB for anything other than Form's, so I have no idea how to start on something which runs in the background.
Thanks :)
A background app won't help in this case.
Ctrl+Alt+Del is specail key combo that is handled directly by Windows and can't be intercepted by a running program.
What this means is that if your game locks up and Ctrl+Alt+Del doesn't bring up the Windows menu, then the game has corrupted the system. The only fix at that point would be a restart.
That being said, you can kill a running process using VB.NET like this:
For Each program As Process In System.Diagnostics.Process.GetProcesses
If program.ProcessName = "ProcessName" Then
program.Kill()
End If
Next
Read more about it on the MSDN.
Okay, so Windows isn't actually locking up, but you just need some way to kill the process. Use the above code, replacing "ProcessName" with the name of your game process, and then either:
(basic) Turn the VB.NET code into an .exe file. Then set up a keyboard macro (using your keyboard software or some freeware) to launch the .exe you made which will kill all running instances of the given process. or...
(advanced) Import "user32.dll" into the VB.NET code, call SetWindowsHookEx with a hook id of 13, a pointer to a LowLevelKeyboardProc function, the handle to your running program, and a thread id of 0. Then, whenever a key is pressed in any program, your KeyboardProc function will be invoked. If the key(s) pressed match your desired kill-key combo, then run the above process killing code. This looks like it may give you more step-by-step instructions.
I am designing an application to connect remotely to another computer. I want to display an NSAlertPanel on connecting however it is 'blocking' the remote side from continuing with the session until OK is pressed with the usual NSAlertPanel setup.
Is there a way to have an NSAlertPanel which is non-blocking? Thanks.
When you run your alert panel modally, you block the run loop of the associated thread, which is the main thread in this case.
To display a window on connection, you can use custom sheets. It's easy to use and explained in the documentation page below:
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Sheets/Tasks/UsingCustomSheets.html
However, if you need to run your alert modally, an alert that is blocking interactions with the whole application, you may need to move your connection part to another thread, which is a good practice in both cases.
I have an issue with WindowsHookEx in vb.net. If my pc is overloaded especially from 3D rendering, windows automatically disconnects my keyboard hook and my hotkeys stop working. I searched around and it seems that there is no way to detect whether a hook is active or disconnected. So I tried this method presented by "moodforaday"
Is it possible to detect when a low-level keyboard hook has been automatically disconnected by Windows?
hook-has-been-automatically-d
He states that using GetLastInputInfo periodically and store GetLastInputInfo to another variable when a key is used and compare the results. If the tick is much newer than your older variable then its likely that its disconnected. Its a great method but the ticks can go up from other things like the mouse. In my Hook class there is no Mouse hook therefore I cannot store a variable of the tick count when the mouse is moved. So now I ended up having it create a new instance of the hook class and hook again. It checks every second if the stored tick is older than new tick by 10000 ticks.
Is it alright to keep creating new instances of Hooks? It will keep Hooking/Unhooking constantly and I'm wondering if that is going to be a problem for Windows.
Also if anyone has another method to detect if a hook is disconnected please let me know would fix this whole hassle.
Do your 3D rendering in a background thread. Use Control.Invoke only for code where you directly access UI controls.
Alternately, you could split the rendering into very small pieces and post them to yourself as messages, to be handled on the main thread. This way you will be able to handle both internal and external messages.
In both cases, your application will be responding in a timely fashion, Windows will have no reason to consider it non-responding, and your keyboard shortcuts will stay in place.
I've written an app for the Mac that is designed as a status bar item. However, when a user opens its menu from the status bar, the main run loop is blocked until it's closed. Since this app responds to messages on a socket, it's a problem that it can't do anything while the menu is open.
I've tried setting the status item from a separate thread and scheduling the socket on a different thread, but no dice. Is there a good way to deal with this?
UPDATE:
I've resolved this now. I was using the NetSocket socket wrapper and its asynchronous nature made it very difficult to open and watch on a different thread. I switched to SmallSockets (another Objective-C socket wrapper) and because it is synchronous, I was able to open a socket and just watch it directly on a separate thread.
While the user is interacting with a menu the run loop runs in the event tracking mode. Attach your sockets to the NSEventTrackingRunLoopMode mode too and they continue to run while the user interacts with the menu.
But putting the sockets on another thread should work too. If this did not work for you, you probably did something wrong, but without seeing the code I can't say.