I see this message in VB6 again and again from time to time since I can remember, and now after like 15 years, I would like to ask if somebody knows how to get rid of this message.
I don't know when it occurs, but when it does, I can not click this window away.
It keeps flickering and does not go away:
In English:
"The action cannot be completed because the other application is unavailable. Click 'Switch to' to activate the other application and fix the problem. 'Switch to...', 'Repeat', 'Cancel' "
I don't really know what the message means. I would guess it wants to tell me that it waits for a component to respond.
But no longer how long I wait, it does not finish.
Does anybody know a trick how to close this window?
Sometimes I can still try to close VB6, and it will go away and allow me to save the edited files, but often, I have to terminate VB6 using the task mananger, and then my changes are lost.
I would like to avoid this.
Thank you!
Edit: It seems that the problem occurs when I use the clipboard.
Each time right now when I use Ctrl + V to paste something, this happens.
Related
Is it possible that Pycharm 'save' the whole staus at a breakpoint and allow the customer repeat debugging from there?
Occasionally I may need to debug a complicate bug which need ~2 hours to reach the target function. The multi-process code consists of many nested invoking and loops. The narrowing down process is pretty tricky. The first breakpoint is easy to set up. But if the second breakpoint was not set up correctly. Or there was one more clicking on 'step over' button. The debug session may exit since there was error. That is terrible since I may need another two hours to start another debugging. If Pycharm allow me to 'save' the debug status at the first breakpoint and allow me back to there whatever the current session ends or not it will be great helpful.
If I could catch up abnormal result before the session exit, then I need to step back during Pycharm debugging to figure out the issue. I searched and found out that both visual studio and IntelliJ has this ability. 'Jumping to Cursor' in Pycharm looks a similar solution. So far I don't have a chance to verify it by using a complex case.
So in genearal, what is the best strategy to debug those bugs which take long time to reach the starting point but failure point/reason is unclear? Thanks a lot.
I have an excel workbook with LOTS of macros.
If I have Excel App. FULLY closed, and I open it, it runs fine.
However if I close the workbook (without closing excel app.), and then I open it again, there is a huge delay when opening, and also while running all the different macros in it.
I have nothing running at the beginning or on the background. In fact, I have put a flag on the thisworkbook Workbook_Open routine....
Just to get to this point (workbook_open event) it takes over 20 seconds! And no macros have run yet !
So to summarize, if opened from scratch (excel app is NOT running), it takes 2-3 seconds for workbook to be opened and ready.
Everything runs fast (macros, etc)...
Then I close the workbook...
If opened again (while Excel already running) takes 15-50 seconds.
Basically anything while working (macros running, etc) takes x 10 longer
If I close Excel app. totally and open it again, it runs nice again (the first time)
I am thinking maybe the workbook has something which affects the memory and the second time it is opened it is affecting it...
But I have no idea, it is just a guess...
Has anyone experienced this ?
Thanks Jook...you send me on the right track and I fixed the problem...
I did a Google search based on "memory leaks" as you mentioned and found some links which advises about the importance of set xxx=nothing
I didn't think it was much of a problem and never thought it could cause such delays (in fact I have lots of other macros/workbooks and never had this problem)
Incredibly that was it, a missing set xxxx=nothing
I went though all the code which run on workbook_open event.
I made sure set xxx=nothing was set on all (I found two missing)
Although it didn't affect the program from running correctly (first time opened), when closing it and reopening it again, that's when it caused a problem ! Weird.
But it is now fixed thanks to you !
I hope this post it helps someone else in future
I am working along in VS2010 and moving code around to make more functions and less clutter, so I copy/paste nine times out of ten my mouse cursor "locks up" and it gets stuck on the arrow pointer rather than the | for text, which is only mildly annoying when you are trying to copy/paste a lot of code around. It clears up whenever I close the file and reopen it, but it interrupts my work flow. Has anyone run into this before, if so, did you figure out how to fix it without closing the file?
I submitted this as a report to MS. I am paraphrasing here, "it is in the bug list and we will look into it."
The only solution is to close the file and re-open it. If MS replies with anything else I will post it here.
My clipboard seems to be 'stuck' - after some time of usage of my machine it simply stops working - any software trying to access it sticks or throws an exception on Ctrl + C or Ctrl + V. The problem persists when I try to access it through the .Net framework or Win32API (an exception is thrown - something like 'Clipboard unavailable' [sorry I couldn't copy-paste it here - my clipboard doesn't work! :)])
I keep on restarting all the time!
I'll appreciate any help or leads whatsoever, thank you:)
I have had seen a similar issue caused by an application which installed a clipboard changed hook (SetClipboardViewer) but later hung. Because it wasn't passing on WM_DRAWCLIPBOARD messages, eventually the clipboard simply stopped operating. Even Windows Explorer drag and drop stopped working.
I suggest that next time this happens to you, you go through all non-base-Windows applications and kill them off, one by one, until the clipboard starts working again. Perhaps use Process Explorer to make sure you're getting them all.
looks like the old SecuRom-bug. There is a fix for that on their website.
I'm writing a DLL that is automatically injected on load in a specific application. Because I'd like to run the program while working on it, and my users might want to load the program without it in specific cases (e.g. bug hunting), I sometimes want to prevent loading the DLL.
Currently I do this by checking GetKeyState for VK_LCONTROL, VK_LSHIFT , and VK_LMENU on load, and if all are down, I silently unload myself.
However, it can take quite a few seconds for the program to load and to see if the DLL was loaded or not, so I want to inform the users when we're unloading. I've considered a MessageBox, but that's too disruptive. I've tried MessageBeep, but that didn't seem to do anything on my setup. Currently I'm using a simple dual beep (Beep, Sleep, Beep) to indicate unloading, but that will probably become rather annoying to my co workers. I've also considered a system-tray icon, but that would introduce a lot of code and bug potential, while I'm aiming for a minimal notification as to not introduce any subtle bugs.
Would anyone else know a subtle way (preferably visual) to inform the user that their input has been succesfully received?
Given the limited scope of your goal, this might actually be an appropriate use of a taskbar notification balloon tip.
Edit: Added link the Joe posted in his concurring answer. Thanks, Joe! :)
If your app has a status bar at the bottom, you could place some message text there...
Have you considered a timed messagebox that closes itself?
http://www.codeguru.com/cpp/misc/misc/messageboxhandling/article.php/c203
You could open a window with a short message and close it automatically again after 0.5 seconds or so. It doesn't need user interaction so I don't think it's very disruptive.
Change the window title, then change it back afterwards. Then you can see the change even if the user has Alt-Tabbed over to some other program in the meanwhile, without stealing the focus from the user.
Concur with Greg D.
Look here: http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/15cbdc8d-fde3-44ab-bbbc-e50cb2071674/
Two ideas:
Turn it around. Have a visual indication when the DLL is loaded, and have the absence of the indicator let you know that the DLL has been unloaded. Perhaps a suffix in the title bar. That way, you can tell at any time, not just during startup.
FlashWindowEx.