Visual Basic

desanti4-Dec-18 8:45

4-Dec-18 8:45

sorry , but my application does respond and it's not dead.
until the point that this error is displayed , all the data are saved on database .
1 second before this error is displayed , a record was saved on database.
But suddenly this error appear , and I have to press continue , and after the execution goes without problem until the end.

so , the application is alive , why windows consider it to be dead ?

Eddy Vluggen4-Dec-18 9:37

4-Dec-18 9:37

desanti wrote:
sorry , but my application does respond and it's not dead.
until the point that this error is displayed , all the data are saved on database .
1 second before this error is displayed , a record was saved on database.
But suddenly this error appear , and I have to press continue , and after the execution goes without problem until the end.

so , the application is alive , why windows consider it to be dead ?

It says literally so in the error; "The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages."

If the app does not process messages, it is considered "not responding". Most apps that go into an uncontrolled loop do not respond to those messages, and it is a way of detecting if the app is still active. If it is doing a lot in one thread, then the thread won't be replying to messages.

Bastard Programmer from Hell Suspicious | :suss:

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.

desanti5-Dec-18 1:18

5-Dec-18 1:18

And what you propose as a solution , because I've read that I should use a background worker , but the problem is that I need to access the UI objects during the process and this is not possible on a background worker.

Eddy Vluggen5-Dec-18 1:43

5-Dec-18 1:43

Since you wont be changing the COM-control, You'd be either ignoring the message, or offering smaller files.

Bastard Programmer from Hell Suspicious | :suss:

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.

desanti5-Dec-18 2:08

5-Dec-18 2:08

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 ?

Eddy Vluggen5-Dec-18 2:37

5-Dec-18 2:37

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 Suspicious | :suss:

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.

desanti5-Dec-18 2:49

5-Dec-18 2:49

there are people that have resolved this with application.doevents :
ContextSwitchDeadlock Errormessage[^]

Eddy Vluggen5-Dec-18 2:52

5-Dec-18 2:52

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 Suspicious | :suss:

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.

desanti5-Dec-18 2:59

5-Dec-18 2:59

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 !!!!!

Eddy Vluggen5-Dec-18 3:01

5-Dec-18 3:01

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 Suspicious | :suss:

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.

desanti5-Dec-18 3:05

5-Dec-18 3:05

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 ?

Eddy Vluggen5-Dec-18 3:09

5-Dec-18 3:09

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 Suspicious | :suss:

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.

desanti5-Dec-18 3:14

5-Dec-18 3:14

But if you see my original error message , it says.... "60 seconds". Maybe this is the time or is another thing ?

Eddy Vluggen5-Dec-18 3:19

5-Dec-18 3:19

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 Suspicious | :suss:

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.

desanti5-Dec-18 3:21

5-Dec-18 3:21

a Timer object will be a help or no ?

Eddy Vluggen5-Dec-18 3:22

5-Dec-18 3:22

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 Suspicious | :suss:

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.

desanti5-Dec-18 3:24

5-Dec-18 3:24

Sorry , Timer Control

Eddy Vluggen5-Dec-18 3:30

5-Dec-18 3:30

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 Suspicious | :suss:

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.

desanti5-Dec-18 3:40

5-Dec-18 3:40

So , the only solution remain to manually calculate the time inside the loop.

Eddy Vluggen5-Dec-18 3:43

5-Dec-18 3:43

..which is not that hard; there's an example a few posts below.

Bastard Programmer from Hell Suspicious | :suss:

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.

Dave Kreskowiak5-Dec-18 5:58

Dave Kreskowiak

5-Dec-18 5:58

No, they haven't "solved" it. What they've done is gotten around the warning message without actually fixing the problem.

Asking questions is a skill
CodeProject Forum Guidelines
Google: C# How to debug code
Seriously, go read these articles.

Dave Kreskowiak

Dave Kreskowiak5-Dec-18 5:56

Dave Kreskowiak

5-Dec-18 5:56

If you think you have to use Application.DoEvents, this is a sign you're doing something very wrong.

Asking questions is a skill
CodeProject Forum Guidelines
Google: C# How to debug code
Seriously, go read these articles.

Dave Kreskowiak

modified 5-Dec-18 22:10pm.