Visual Basic

Close 'alert' windows in webbrowser control

28-Sep-08 4:42

Perhaps you would get more answers on ASP.NET [^]-forum

The need to optimize rises from a bad design

Member 377616228-Sep-08 0:37

Member 3776162

28-Sep-08 0:37

Hi, i had developed a application for automatic navigation in URL and save information to disk. I'm using webbrowser control.

All is correct, but, i have a problem!!!
When the application is navigate, 'alert' window is open and the application stop.

How i close 'alert' window in code ???

I supossed the solution is complicate but I'm sure this is possible.

Thanks

Timer_Tick event not called

Sonhospa28-Sep-08 0:30

28-Sep-08 0:30

Hello gurus Smile | :)

the funny little problem now comes from a timer component. The main code starts the timer (interval 1) and - right afterwards - a BackgroundWorker component. I intend to count the seconds which the BW needs for his task.

Realizing that the time-label in my form wasn't updated (through 'lblTimer.refresh' in the Timer_Tick event), I stepped through the code and had to see that the Timer_Tick event just isn't called at all D'Oh! | :doh:

and even a stopmark I placed within the event was ignored. Searching for possible reasons didn't bring me much further yet.

My question: Is there anything (apart from stopping the timer) that makes VB ignore the Timer_Tick event completely? Or are there any imaginable reasons for that behavior?

Thank you for inspiration,
Michael

Wendelius28-Sep-08 4:40

28-Sep-08 4:40

Most likely the timer isn't enabled or Timer_Tick event isn't wired.

Also reconsider if you really need interval of 1 millisecond.

The need to optimize rises from a bad design

Sonhospa28-Sep-08 5:10

28-Sep-08 5:10

Hi Mika,

as the timer is surely enabled I have to ask you what 'it isn't wired' would mean? I thought as soon as the timer is started the tick-event would start until the timer is stopped?

You're surely right regarding the interval which I had set to 100 before. When I'm back to a reliable tick-event I guess I can switch that back since it's only needed for the form's update. I hope with your help I'll have a timer-tick again soon ...

I found a weird effect, too: running the app from debug-mode, the tick-event seems to run sometimes and therefore update my timer-label - I just can't tell the exact conditions. It feels a bit like the Backgroundworker eventually blocks the timer...(is there no 'DoEvents' or similar command to put there anymore?) like under 'race conditions'.

I thought I'd probably post a part of the code:

Private Sub Main()
    UpdateDriveInformation()
    ProgressIndicator.Style = ProgressBarStyle.Marquee
    startTime = Now
    Timer.Enabled = True

    If PROC_MAKELIST Then
        ThreadID.Text = TXT_MAKELIST
        BackgroundWorker2.RunWorkerAsync()
    Else
        ThreadID.Text = TXT_DELREPORTS
        GroupBox1.Text = TXT_MAKELIST
        BackgroundWorker3.RunWorkerAsync()
    End If
End Sub

Private Sub Timer_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer.Tick
    Dim mDbl As Double = Now.ToOADate - startTime.ToOADate
    Dim mDat As DateTime = DateTime.FromOADate(mDbl)
    Try
        Dim mDat2 As Date = Date.FromOADate(mDbl)
        lblTimer.Text = mDat2.ToString("mm:ss")
    Catch ex As Exception
        lblTimer.Text = "Timer Error!"
        Err.Clear()
    Finally
        lblTimer.Refresh()
    End Try
End Sub

Maybe you see something wrong here?

Thanks for now

modified on Sunday, September 28, 2008 11:35 AM

Wendelius28-Sep-08 5:34

28-Sep-08 5:34

By wiring I mean that you have an eventhandler attached to the objects event. From your code I suppose that Timer refers to the object drawn to the window.

At a glance I don't see anything special in your code but all necessary operations are not included. I take it that the rest is defined in Designer.vb (for example interval and so on).

One possible problem you may encounter is that Tick isn't necessarily raised while debugging. This could be one reason why it sometimes is run and sometimes not.

The need to optimize rises from a bad design

Sonhospa28-Sep-08 5:49

28-Sep-08 5:49

Thanks for checking.

You're right, I did the form in the designer and it refers to lblTimer - which is nothing than kind of a stopwatch - drawn to the window. After building an exe and starting it several times, I have to say that it's exactly the same effect: Sometimes it starts counting (one or two seconds was the maximum), sometimes the label just stays at 0.

Would it be possible that the Backgroundworker blocks the timer... something like 'race conditions'?

modified on Sunday, September 28, 2008 1:00 PM

Wendelius29-Sep-08 3:31

29-Sep-08 3:31

For a race condition you should use a common resource in both threads. And even if that's true, it should appear when you use the resource, not on timer tick.

However, it's possible that you are blocking the whole UI thread (I take it that the timer is in main UI thread) and in that case the tick won't occur. If that's true your UI should also be non-responding.

There's also the possibility that the timer's enabled property goes to false. Try using debugger and add a conditional breakpoint to timers enabled property and define the debugger to stop every time the value changes. This helps you to eliminate that possibility.

The need to optimize rises from a bad design

Sonhospa29-Sep-08 3:58

29-Sep-08 3:58

Hi Mika,

thanks for still taking care.

Mika Wendelius wrote:
The need to optimize rises from a bad design

I have to admit that being a newbie I seem to fall into almost every bad design trap I can find Sigh | :sigh:

What I did meanwhile is that I eliminated Mad | :mad:

the timer as well as the Backgroundworker. Instead of that, the looping function (which used to be in the background worker) calculates the time elapsed within every loop and updates my lblTimer label. This way might not be elegant (and I still didn't learn how to use the Timer right) but it works $Shucks | :-\$ for my small purpose and I see how much time the function needed.

Mika Wendelius wrote:
However, it's possible that you are blocking the whole UI thread (I take it that the timer is in main UI thread) and in that case the tick won't occur. If that's true your UI should also be non-responding.

I had started the timer in the main UI thread of a form, in which (I guess) also the Timer_Tick event runs (I placed the component in the form). The update of the lblTimer label was supposed to come from the Timer_Tick event (after starting / before ending the timer) every second and independently from the looping stuff done in the backgroundworker (that was the idea). Other controls (a progressbar and another label), which are updated in the backgroundworkers ProcessChanged event, do update with every loop!

Do you think it's possible that the BW takes so much of the processor time that it doesn't leave any for the main thread? Somehow that doesn't make sense for a backgroundworker, does it?

Wendelius29-Sep-08 4:19

29-Sep-08 4:19

Oops,

That optimizing thing is only my signature. I think I should remove so that people won't take it badly. It certainly wasn't targeted to you! Sorry for that.

If you're reading or updating lblTimer in background worker, you may block the timer (or actually the UI) and it can cause you several other problems since UI elements must be updated only in UI thread. Also if the backroundworker continuously uses the lblTimer, it may cause a collision with the timer in event handling.

Just a question: Why don't you update the elapsed time in Timer_Tick instead of using backgroundworker? It could simplify the code a lot. For what you described I don't see the benefit of using backroundworker. Another possibility is to use two separate timers in which case they would still be under the same thread, but I'm not sure that iven that is needed

Mika

The need to optimize rises from a bad design

Sonhospa29-Sep-08 5:03

29-Sep-08 5:03

Don't mind your signature Wink | ;)

it's a good reminder to learn, anyway, and I didn't take it personally.

Something you misunderstood: I didn't update lblTimer (a label on the main form) in background worker, but in the Timer_Tick event. Other controls (progress bar etc.) were updated in background worker (process_changed).

The use of a background worker arose from the idea NOT to block the UI with long lasting (looping) function (purpose: listing of large directories in a given path). So my basic concept for that seemingly simple thing was:
1. Start the timer from the forms main routine
2. Start a background worker (also from the forms main routine)
3. Let the timer count the seconds while user sees a marquee-style progress indicator as long as the background worker is running
4. Stop timer when background worker is finished

Actually I tried out the whole BW / Timer stuff to learn something about better design Wink | ;)

but it seems I'm trapped somewhere WTF | :WTF:

Wendelius29-Sep-08 5:56

29-Sep-08 5:56

Ok,

As far as I can tell, the basic idea seems good. And if the backgroundworker isn't accessing any UI elements directly, you should be safe. However, if the timer and the BW share some variables, arrays etc, you should lock them before accessing (not sure what is the keyword in VB but in C# it's lock).

Perhaps if you strip the code to the minimum and then try bringing it back piece by piece, you'll find out what went wrong.

The need to optimize rises from a bad design

Sonhospa29-Sep-08 6:17