Okay, I have had the most aggravating problem with OpenFileDialog1. I have a program that I've been using for some 8 months, and in the past month, the program has begun to hang randomly when utilizing the OpenFileDialog1.ShowDialog() function. I have already read through all of the other posts about multi-threaded vs single threaded application. This did not fix it. Enabling the "Show Help" button did not fix it. I am mostly at a loss. here is a thorough walkthrough of the bug:
Run the application. I can always use the Open File button a few times with no problems. It freezes randomly after the program has been running for awhile.
The freeze happens after I push the ShowDialog button, and never displays the Open File Dialog window. The entire program locks up and hangs. If I pause it, Visual Studio doesn't show an error. It underlines the OpenFileDialog1.ShowDialog() in green, which is very odd.
I have found a way to break the freeze. Simply run a second instance of the program and use the OpenFileDialog function. As soon as it loads the file in the second instance, the first instance unfreezes. However, this is not a fix.
The only thing I can think of that may be causing this is the program also uses a WebBrowser1 control. It only seems to happen AFTER the WebBrowser control, which is on a seperate form, not the main form, has been initiated and utilized. Does this make any sense at all?
Thank you for anyone who can help me. I am about to tear my hair out.
Debug your program with dnspy, And when the software freezes, you will be able to see within the dnspy the actual code even if it is in a third party DLL.
I have solved this problem. It was quite unsolveable based on my description above, but hopefully I will help someone with this solution. The error is related to using the IE11 Emulation Control (11000) in the WebBrowser1 control. For some reason this interferes with OpenFileDialog and causes it to hang. I have no idea why. I changed my WebBrowser1 to use IE9 Emulation Control (9999) and the error has gone away. Thank you to those who looked into this. This is a registry entry in HKEY_CURRENT_USER.
Related
So here's a head scratcher. Recently I finished a program in VB that have several GroupBox to place my buttons in. And during testing in my PC everything worked out fine.
But when I want to test it on user PC, the program immediately pop up a "The program is not responding" message and stops process immediately without even showing the form. The user PC does not have Visual Basic 2010 installed.
After experimenting further I found out that the GroupBox were the cause, when I removed them the program can run in user PC fine.
So yeah... Till now I don't know why GroupBox doesn't want to play well like this. Is this a common problem in general?
P.S. I don't know if this is the right place to ask this. If not please let me know and I'll remove this question. Thanks.
I'm writing a VB program where I want to be able to "push" an Exit button with a keyboard shortcut to close the program. I understand that if I put an & in the text of the button (E&xit), I can create a Alt-X shortcut to exit.
I've written programs where it's worked before; it's simple, but now it's not working. In fact, it's not even underlining the x in the text on the button. It's like a setting is telling it to be ignored. (I'm using the latest version of MS Visual Studio.)
I have found that if I turn on the form setting KeyPreview=True, it will work, but the x is still not underlined, so there is no visual indication of the shortcut being available. I feel like I'm missing some setting or switch that make this activate normally. Can someone explain or point me in the right direction? Thanks.
jmcilhinney, well, now it's working, both on new and existing apps, even with keypreview turned off. I think there was something strange going on with Visual Studio that day. Other parts of my program (with KeyPress handling) were not working correctly either at that time. Then suddenly everything started to behave as expected. Or maybe it was something I was doing with Keypress that messed up the Access Keys. I wish I could explain better, but now I can't reproduce the problem.
I used to program in VB6 professionally (up to about 6 years ago). Now I'm trying to write a personal program in Visual Studio 2017 Community. I'm having a problem:
I had the program finished but needed to embed an ICO file in the EXE and couldn't get it to work. Somewhere in the process, I screwed something up. None of my "code-behind" stuff is running. That is, form_load doesn't run, none of the code associated with the buttons runs when clicked upon, nothing. Double-clicking a button to see the code behind it actually brings up the Form1.Designer.vb window (which I'd not seen before).
It's as if all the code behind the form has been orphaned and the form and the code which had been associated with it have been separated. I'm sure I did something stupid while monkeying with settings to try to get the ICO file to embed but I have no clue what I did wrong.
Suggestions? Please. :-/
--HC
I've got a problem with vb6.
Using an HMI vb6 developed interface in a automated machine, it sometimes crashes with out of memory error.
initially it happens using a particular form, so i tried set it up well, now happens less time but in random form.
These forms are in a dll file and in HMI exe file.
I cannot debug that because it's quite difficult reproduce that error.
Thanks
Problem solved,
there was a couple of line that handles other modal forms despite the main current form was a modal too. so systems continue ping focus between different windows, after tot minutes, it crashes.
I have some code in Form Load event. It is doing fine. But when it reaches to pick data from database, no commands are executing after that. There is no error at all but it just goes silent.
I tested it as follows:
MsgBox("1")
vrStudentName = DsGetPprStatusfromEnrSummary.tblPaperEnrSummary.Rows(0).Item("StudentName")
MsgBox("2")
Please advise.
Thanks
Furqan
Message Box one is showing data but not the message box two. In fact, the second message box statement is not showing any response at all.
This is a nasty problem on 64-bit operating systems. Any exception raised in code that's run from a form's Load event is swallowed without a diagnostic. This is an old problem that is not getting solved because the DevDiv and the Windows groups at Microsoft are pointing fingers at each other. My finger is pointing at the Windows group but that doesn't help either.
Two basic ways to solve this problem:
Project + Properties, Compile tab, scroll down, Advanced Compile Options, change the Target CPU option from x86 to AnyCPU. This disables the Wow64 emulation layer that swallows the exception.
Debug + Exceptions, tick the Thrown box for "Common Language Runtime Exceptions". The debugger stops as soon as the exception is thrown.
Also keep in mind that it is very rarely necessary to use the OnLoad method or Load event. Only code that requires the Size or Location or Handle of the form to be accurate needs it. Anything else belongs in the constructor of the form. That Load is used so often is a VB6 anachronism, carried over in the designer design which made the Load event the default event for a Form. Add a constructor by typing "Sub New".
Well, it seems pretty obvious that the call to DsGetPprStatusfromEnrSummary.tblPaperEnrSummary is never returning; which means the problem is IN THERE somewhere.
So what on eath is it? I'm guessing it's a DataSet, yes?
But you've referenced it staticly, which is YuckyPooPoo(TM) IMHO, because it's a complex artifact, and you've rendered EVERYTHING which references it unisolatable, and therefore fundamentally untestable!
Received answer on Codeproject
In the dialog that comes up, put a tick in every checkbox under both "Thrown" and "Unhandled". Press OK.
Now, when you run your app though the debugger, it will break for any exception, even if you have an active handler. This should help you track down the problem.
Issue RESOLVED