|
Since you wont be changing the COM-control, You'd be either ignoring the message, or offering smaller files.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I can't offer smaller files.
also I've read that I can do some configuration to ignore the message.
but the problem is , what about when I finish my program and install it to client pc ?
I've read also that I can use application.doevents.
But executing this on every step of the loop cause the program to slow down.
Is there way to call this only when necessary so windows can detect that my application is alive ?
|
|
|
|
|
desanti wrote: also I've read that I can do some configuration to ignore the message.
but the problem is , what about when I finish my program and install it to client pc ?
You can; the IDE only breaks on exceptions that you want it to. What happens without the IDE can easily be tested by running your app outside of it. Then you'll know what happens on the client-PC.
desanti wrote: I've read also that I can use application.doevents.
No, you can't.
desanti wrote: But executing this on every step of the loop cause the program to slow down.
It is a loop inside a COM-component. Do you have the source to that control?
desanti wrote: Is there way to call this only when necessary so windows can detect that my application is alive ?
You application IS alive (and answering messages), but the COM-component that you're using is not. If you know WHY it is not answering messages, then it is not a problem. You simply wait for it to be done and hope it is not in an endless loop.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
If the loop is in your program, then it should be in a backgroundworker on its own thread. If the loop is inside the COM-component, you can't change much.
Application.DoEvents is a crutch for people doing too much on the UI-thread.
--edit
Go to the menu "Debug / Exceptions", find "Managed Debugging Assistants", uncheck ContextSwitchDeadlock.
And sometimes, the message is even bogus[^].
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
the loop is inside my program , but the problem is that inside the loop I use the values from some controls in my form ( there's a spreadsheet control that have all the data from excel file or directly written by user and some other textboxes that have all the data and parameters that I use on that loop). so I can't use a background worker because I've read that I can't use the UI controls inside it. Or I'm wrong !!!!!
|
|
|
|
|
desanti wrote: so I can't use a background worker because I've read that I can't use the UI controls inside it. Or I'm wrong !!!!!
You can't access them directly, you'd have to do an invoke.
Is this actually occuring in the release-version?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yes , I noticed at least 2-3 times in the release version.
I've tried with Application.doevents executed on every step of the loop , and no problems but the application slows down.
So i'm asking if there's a way to know the interval that windows check for application status , so i'm calling application.doevents not on every step of the loop but for example every x seconds ? Is this possible ?
|
|
|
|
|
desanti wrote: So i'm asking if there's a way to know the interval that windows check for application status , so i'm calling application.doevents not on every step of the loop but for example every x seconds ? Is this possible ?
I never found any specification on how often Windows checks it, might even vary between versions. Instead of doing it every N seconds, you could do it after N items. Still, that metric may vary on another system.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
But if you see my original error message , it says.... "60 seconds". Maybe this is the time or is another thing ?
|
|
|
|
|
Yup, that's what it says, you're right. Get the current time before the loop.
Inside the loop, distract that value from the current time. If the difference is more than N seconds, call your doevents.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
a Timer object will be a help or no ?
|
|
|
|
|
Which timer-object? There's multiple, and one of them relies on the application processing messages (ie, not being too busy).
It's easier to simply check inside the loop how much time has passed.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
The one from System.Windows.Forms says this in the docs;
Implements a timer that raises an event at user-defined intervals. This timer is optimized for use in Windows Forms applications and must be used in a window. Meaning it won't fire if it doesn't get to process the message.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
So , the only solution remain to manually calculate the time inside the loop.
|
|
|
|
|
..which is not that hard; there's an example a few posts below.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
No, they haven't "solved" it. What they've done is gotten around the warning message without actually fixing the problem.
|
|
|
|
|
If you think you have to use Application.DoEvents, this is a sign you're doing something very wrong.
modified 5-Dec-18 22:10pm.
|
|
|
|
|
Solution? Ignore it. The message only shows up when debugging the app.
And you're wrong about the BackgroundWorker not having access to the controls. Technically, you don't have access to them, but you can get at the controls if you supply method to update the controls and Invoke calls to them. Using the BackgroundWorker, or some other threading/Task model, will free up the UI thread to pump messages. This will also make the warning message you're seeing disappear.
Also, if you're doing everything in this long-running operation on the UI (startup) thread, then your controls are not getting repainted anyway. If the UI thread is busy with your operation, it can't respond to all the WM_PAINT messages that are piling up in the message pump. So, during this operation, what could you possibly be updating in the controls since nobody can see those changes?
If you're going to do a long-running operation with control interactions, you have to do it correctly, otherwise you run into little issues like what you're seeing.
|
|
|
|
|
I could install visual studio 6.0 on my windows 10 system as per the article of this code project and my Visual Basic package worked very well for six months.Two months back I found the package is not working and I tried to reinstall number of times, but it couldn’t be installed. I find that VB98 folder exists and VB6.exe is starting and displaying form, but form code screen will not be displayed and closes the project screen.
I could install visual studio community 2017 (for Home) on my windows 10 system and I find conversions of my Visual Basic package is likely to take long time. Can someone help me how do I proceed for installation of visual studio 6 on my windows 10 system.
|
|
|
|
|
Just what is your expectation here, you are asking how to install a product that is no longer supported onto the current OS. Nobody without a REALLY compelling reason will be doing this and it is highly unlikely that anyone is gong to be able to help.
I'm sure you have heard it before... Rewrite your application into a current language if you expect to get any help.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
It may very well be due to some Windows 10 updates. I managed to install it following the CP article but it was on a LTSB machine, with no Cortana, Store nor updates (there were few of them and I axed them altogether).
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Hi,
Visual Basic 6 is no longer supported. Many of the VB6 ActiveX control CLSID have been set to COMPAT_EVIL_DONT_LOAD because of security issues.
Best Wishes,
-David Delaune
|
|
|
|
|
Well, I can tell you that VS 6.0 works fine on all of my Windows 10 systems. (desktop is build 17134.407) That's a really strange problem you are describing and one that I've never encountered in 20 years with VS 6. You could try event viewer or procmon to find what's failing. One other suggestion is setting up a VM with an older OS. I do seem to recall that on the first startup, you have to uncheck the add-in for Visual Component Manager.
As for migration to .NET, I'd suggest finding VB 2008 Express which is the last version to include a VB6 migration utility. I have found the best results have come from stripping all the code and letting the migration tool upgrade the forms, then go back and paste in/rewrite the code block by block. It's tedious, but better than dealing with hundreds or thousands of migration notes/errors at a time. Good luck!
"Go forth into the source" - Neal Morse
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
