Long story short: I'm trying to write an app that'll dump IE's history to a text file. Because I am lazy, I went searching for a preexisting library and found this beautiful project to build from: http://www.freevbcode.com/ShowCode.asp?ID=6702. Only, I'm stuck...
I finally got the program to dump the history, but it only works if I put a MsgBox() on line 169 of Module1.vb. I've tried putting a Thread.Sleep() there, but that doesn't work. There has to be a message box there, or only today's history gets listed.
My guess, since this is talking to wininet.dll, is this is a concurrency thing. Thread.Sleep() (for a For...Next loop) stops the program from listening; nothing there makes it exit the loop before values are assigned, but a MsgBox() is just right. Is there something besides MsgBox() that will have the same effect? I'd like to not have to hit OK thirty times to make the program work.
Here's my branch/version/derived work: http://profnano.org/andy/misc/img/HistList.zip; it's a VS.NET2003 project.
MsgBox() pumps a message loop. That can get all kind of code unstuck. Windows get a chance to paint themselves. COM deadlocks due the main thread getting stuck in a loop are solved, always an issue when IE is involved. Calling DoEvents() is the very imperfect alternative to MsgBox().
Related
I have exactly the problem described here:
From what I can see on the web, this is a fairly common complaint, but answers seem to be rarer. The problem is this:
We have a number of Excel VBA apps which work perfectly on a number of users' machines. However on one machine they stop on certain lines of code. It is always the same lines, but those lines seem to have nothing in common with one another.
If you press F5 (run) after the halt, the app continues, so it's almost like a break point has been added. We've tried selecting 'remove all breaks' from the menu and even adding a break and removing it again.
We've had this issue with single apps before and we've 'bodged' it by cutting code out of modules, compiling and then pasting it back in etc.
The problem now seems to relate to Excel itself rather than a single .xls, so we're a little unsure how to manage this.
I have managed to resolve it with the accepted answer, but now, when I send the VBA file to my colleagues, they have the same problem.
My question and my problem is - any ideas what to do, as far as it is really not a good idea to go to everyone and to debug every time. And I somehow do not want to add Application.EnableCancelKey = xlDisabled to my macros.
Sounds like a ghost break. File saved one time with a break in there. What has worked for me in the past was to remove any breaks you see and manually step through the code (F8) through completion and then save file. Prob now necessay to step all the way through but I like to know I went all the way and didn't miss any.
My Labview Program works like a charm, until I look at the Block Diagram. No changes are made. I do not Save. Just Ctrl+E and then Ctrl+R.
Now it does not work properly. Only a Restart of Labview fixes the problem.
My Program controls two Scanner arrays for Laser Cutting simultaneously. To force parallel working, I use the Error handler and loops that wait for a signal from the Scanner. But suddenly some loops run more often than they should.
What does majorly happen in Labview when I open the Block diagram that messes with my code?
Edit:
Its hard to tell what is happening without violating my non-disclosure agreement.
I'm controlling two independent mirror-Arrays for Laser Cutting. While one is running one Cutting-Job, the other is supposed to run the other Jobs. Just very fast. When the first is finished they meet at the same position and run the same geometry at the same slow speed. The jobs are provided as *.XML and stored as .net Objects. The device only runs the most recent job and overwrites it when getting a new one.
I can check if a job is still running. While this is true I run a while loop for the other jobs. Now this loop runs a few times too often and even ignores WAIT-blocks to a degree. Also it skips the part where it reads the XML job file, changes the speed part back to fast again and saves it. It only runs one time fast.
#Joe: No it does not. It only runs once well. afterwards it does not.
Youtube links
The way it is supposed to move
The wrong way
There is exactly one thing I can think of that changes solely by opening the block diagram.
When the block diagram opens, any commented-out or unreachable-code-compiler-eliminated sections of code will load their subVIs. If one of those commented out sections of code were somehow interfere with your running code, you might have an issue.
There are only two ways I know of for that to interfere... both of them are fairly improbable.
a) You have some sort of "check for all VIs in memory" or "check for all types in memory" that you're using as a plug-in system. When the commented-out sections load, that would change the VIs in memory. Such systems are not uncommon when parsing XML, so maybe.
b) You are using Run VI method for some dynamically invoked VI to execute as a top-level VI, but by loading the diagram, it discovers that it is a subVI of your current program. A VI cannot simultaneously be top-level and a subVI, so the call to Run VI returns an error.
That's it. I can't think of anything else. Both ideas seem unlikely, but given your claim and a lack of a block diagram, I figured I'd post it as a hypothesis.
In the improbable case someone has a similar problem. The problem was a xml file that was read during run time. Sometimes multiple instances tried to access it and this produced the error.
Quick point to check: are Debug and "retain data in wires" disabled? While it may not change the computations, but it may certainly change the timing of very tight loops, and that was one of the unexpected program behaviors, OP was referring to.
This has been a long and unresolved problem with Excel VBA code that runs a repeated loop via the Application.OnTime Now + TimeSerial(x,x,x). Users will find that their code is running fine for a few days and may, or may not, mysteriously stop.
I'm facing such a situation and hoping to resolve it. I've read over 30 forum answers, some written by experienced developers, and came to this understanding. My conclusion and question follow.
The conclusion is that Excel randomly goes into a break mode but no one knows the reason why this occurs, more so, why it randomly occurs.
Shall we then conclude that in fact this randomly occurs? And that Excel VBA isn't as robust as other languages.
Some notes:
I know this can be resolved by pressing Ctrl+Break twice. It doesn't explain why we have to do it in the first place.
I realize that this error is code independent. It'll occur with both simple and involved programs.
After trying multiple ways to simulate this error, and I mean a lot - long and multiple ADODB SQL connections and queries, cell editing while macro is running, using multiple and 1 second Application.OnTime recursive calling, I can't replicate the error. It is truly random.
I'm running only one workbook and one Excel instance.
Some say, for each break point we did in the debugging, that break point remains in memory. And then when we run a macro in the future, a write to that part of memory triggers this random break. This is a plausible explanation and does conclude that this error is random. No way can we inspect memory in VBA.
I need something to go by, even if it isn't to solve this problem, to act as proof for my boss.
I've solved the bug! I've not read this answer to this problem before so it is pivotal that the Excel community receives this.
Excel fails to call its sub routines in the Application OnTime queue whenever this happens. You have started to edit a cell, stayed in edit mode, and then switched away from Excel either by minimizing the window or by clicking onto another window.
All the sub routines in the Application OnTime queue will wait until the cell is finished editing. So once you switch back to Excel, the cell switches edit mode off, and then all the sub routines will run.
I'm actually quite impressed I solved this myself.
I'm pretty new to VB .net still and I'm attempting to write a program that constantly watches information pulled from a PLC and updates when it changes.
I've worked some with microcontrollers and I know making an infinite loop works well. What I'm running into with my VB .net code is when it loops, the form basically freezes up and the label never updates. I attempted using the code below.
Do While True
*Code*
Loop
So, I guess my first question is, what is the best way to go about having a continuous program to update data. It seems an infinite loop is not the answer.
My second question is, like microcontrollers, is it possible to have VB .net be an interrupt driven program instead of an event driven. My program is always running, updating the data as it comes in, but if a button is pressed it can essentialy break out of the loop. Or what I have in mind, temporarly leave the loop to perform another function then continue back into the loop.
I've looked at the System.Timers namespace, and am not 100% clear on how they work. It seems like it is potential answer to my problem. If I have a timer that does the code every one second, this one second occures as long as the form is running correct? Assuming the previous statement is correct, if the code is running from the 1 second tick, and a button is pushed while that code is running, will the button be ignored, or will the event happen after the code has finished.
Anything to help me learn will be greatly appeciated!
You can use the
Application.DoEvents()
-method provided by the .NET framework, it essentially updates your form to apply all the changes that happened in the meantime.
I'm creating a fairly extensive Excel user form making use of several custom classes I've written. Things currently seem to work as expected, but sometimes when I close the form a process appears to still be running in the background.
I know this because after closing said form, sometimes a CPU core keeps running at full capacity, and when I click on a cell in my spreadsheet the value shown in the formula bar blinks rapidly, as if the spreadsheet were being repeatedly refreshed.
I've tried inserting breaks and debug statements in the Class_Terminate functions of each class (or at least all the big ones), and they all seem to deconstruct neatly. Furthermore, when I rest at a code break, everything halts as expected.
So, what gives? Is there a better way to isolate the problem? How can I find out what's still running after I close my userform?
Well, after some aggressive commenting and uncommenting, it seems like my error has to do with VBA's destructor functions, Class_Terminate().
I have a "WellReader" class within a "WellCollection" class, so when I terminate my WellCollection class, it destructs WellReader along with it. However, if I have Class_Terminate() defined for both classes, it throws my program into a loop (literally). Simply defining the functions causes the error, even if there's no code within them.
(Here's a related StackOverflow post that sheds some amount of light on this issue.)
So, while I'm not sure why both destructor functions won't work, for now I'll do without one. Thanks for everyone's help!