[RESOLVED] Buttons don't display when in 'while' loop

[vinniewryan]

Hello,

I'm fairly new to VB 2010 but very familiar with programming in other languages. I'm trying to make a quick application but I'm at a stand still. I know it's something simple but I've searched around and I may have found the answer but because I don't understand the problem I'll never know. So here goes.

I'm not at my programming station at the moment so I'm going to be very general with my example. Here's what I want to do:

dim doonce as Int16

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) 
{
doonce = 1
}

Protected Overrides Sub OnPaint(ByVal e As
System.Windows.Forms.PaintEventArgs)
bm as new bitmap
while(doonce = 1)
{
   bm.clearcolor(white)
   bm.setpixel(0,0(black))
}
End Sub

So basically the while loop never executes when I click the button. This obviously isn't the exact code, but it's an idea of what I'm trying to do.

basically when you click the button, it refreshes the bitmap and sets a pixel. In the final code, the pixel position will increment each time you click the button.

[vinniewryan]

Also, when I force the while loop to run by setting doonce to 1, the button disappears.

[Shaggy Hiker]

I'd have to say that the difference lies in the difference between the pseudocode and reality. That button click won't cause a redraw, so the paint event wouldn't be raised. If, instead, you had added a Me.Refresh, after you set the doonce variable in the button handler, then that would cause a paint event.

Why the button goes away certainly isn't clear from what you have shown.

[vinniewryan]

So if the button refreshes itself, that will cause OnPaint to see the change in value of doonce?

[Techno]

correct.
when you are in a loop, then your form will become unresponsive because it is performing your loop (on that form). refreshing the button will raise the OnPaint event causing it to redraw itself forcefully, yes.

however not knowing your purpose for doing a loop on the OnPaint which does the same thing again and again... why would you want to do that?

in any case:

button1.Refresh()

[vinniewryan]

The while loop is there to constantly read information from the COM port. The com port is connected to a camera which sends B/W pixel data. The loop reads that data and sets the cooresponding pixels. My setup is Camera -> micro controller -> COM PORT ->

The while loop is initiated when the COM PORT receives a command telling it that a new frame is available. When this happens, COM will receive 900 (30X30) pixels and set 30X30 pixels of the bitmap using OnPaint. Once it reaches the last pixel, the bitmap will be refreshed and the loop will end.

The button is just there for testing.

[Techno]

cool

[Shaggy Hiker]

In that case, the whole thing won't work the way you want it to. Now I know why the button is disappearing. You have to move that read, and the loop itself, out of the UI thread into either a backgroundworker object, or into a thread all of it's own. When that loop runs, it will block the processing of incoming messages. The button disappears because it gets invalidated, but the code to redraw it never gets to run because the loop is blocking EVERYTHING else that relates to UI, all button presses, all screen updating, everything. Putting the com reading loop into a different thread will solve that.


EDIT: By the way, Me.Refresh will refresh the whole form, not the button. Me refers to the form, as the form is the class that is calling this. You happen to be working in the button click event, but the button is nothing more than an object on the form, and therefore isn't Me (it is, however, sender, so sender.Refresh would redraw the button, but that is likely not what you need to do anyways).

[Techno]

whilst it is true what shaggy has said, by enforcing the Refresh, it is guarenteed to refresh/redraw that control even currently how it is developed.

but yes, best practice is to have this operation on a seperate thread.

[Shaggy Hiker]

whilst it is true what shaggy has said, by enforcing the Refresh, it is guarenteed to refresh/redraw that control even currently how it is developed.

but yes, best practice is to have this operation on a seperate thread.

I came back to correct one item in my edit, and saw this. The correction for the edit is that sender is the button, but it is type Object, so sender.Refresh wouldn't be possible. Instead, sender would have to be cast to either Button or Control so that .Refresh would be an option.

As for this, Invalidate would not work, since that just queues up the paint message. Refresh is more imperative, but it still won't really work, because the UI will become unresponsive while the loop runs, and that can result in some very strange painting behavior when you get to painting an entire form like that.

[vinniewryan]

Okay so if I move the while loop outside of the OnPaint thread, how can I reference OnPaint to use the Set.Pixel() command? Would I do something like

OnPaint.Set.Pixel()

??

or bm.Set.Pixel()

'where bm is the bitmap object

Perhaps you can tell me what to change in the following:

dim doonce as Int16

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) 
{
doonce = 1
}

Protected Overrides Sub OnPaint(ByVal e As
System.Windows.Forms.PaintEventArgs)
bm as new bitmap
End Sub

Sub ShowPixels()
   while(doonce = 1)
   {
      bm.clearcolor(white)
      bm.setpixel(0,0(black))
   }
End Sub

I believe this will give me an error that bm is not declared..

EDIT: By the way, I'm not using the COM reading loop in this test so it's irrelevant at this moment.

[Shaggy Hiker]

Yeah, that would give you an error. Why do you want to declare the bitmap inside the paint routine. I realize that this is pseudocode, but it isn't actually clear that the bitmap is being displayed. You can work with a bitmap anywhere you want, and I would suggest that you do. If you want to show the bitmap, such as in a PictureBox, or some other control, that doesn't have to happen in the Paint event. You would just have to invalidate the control after you make some change to the bitmap.

[vinniewryan]

hmm, I believe the other error I was getting was that when I try to use set.pixel outside of the OnPaint sub, it tells me that e is not part of system.drawing or something to that effect. I'll copy the actual code and paste it here over the weekend if I can't figure it out with your current help.

Thanks :]

[Shaggy Hiker]

Yeah, e certainly wouldn't be. Perhaps you were getting the graphics object from that. Anyways, the real code will help a lot more than guesses.

[incidentals]

whenever you commit to a loop that

(1) may take a while
(2) may need to be cancelled or stopped

you need to all ow the rest of the programmed environment time to react to what ever commands need to be heard within the loop

normally I would suggest including a "doevents" that allows every other running thing the chance to be heard refreshed or whatever

here to talk (generally - in lue of best practice that has served me well for 30years)

[Techno]

DoEvents - bad practice. spanky spanky.
you will get unexpected results and behavior of you do this.

[Shaggy Hiker]

I'm not nearly as opposed to DoEvents, but this still seems like a good place for a background loop. Still, we've gone about as far as can be gone with pseudocode.

[vinniewryan]

So here's the code. I added 'Refresh' and it seems to work, though if this is not the correct approach please correct me.

    button(bla bla) onClick
        doonce = 1
        Me.refresh()
    end button

    Protected Overrides Sub OnPaint( _
        ByVal e As System.Windows.Forms.PaintEventArgs)
        Dim bm As New Bitmap(30, 30)
        Graphics.FromImage(bm).Clear(Color.Black)

        While (doonce = 1)
            If (currentpixY < 30 Then)
                If (currentpixX < 30 Then)
                    bm.SetPixel(currentpixX, currentpixY, Color.FromArgb(255, 255, 255))
                    currentpixX += 1
                else
                    currentpixY += 1
                    currentpixX = 0
                End If
            Else
                e.Graphics.DrawImage(bm, 0, 0)
                currentpixY = 0
                doonce = 0
            End If
        End While
    End Sub

This now refreshes the bitmap once every time I click the button.

[Techno]

not sure if you are using doonce just to set the value 1 or 0 but if you are, then you are better to use boolean instead (true/false)

[Shaggy Hiker]

Doesn't that loop just draw two lines on a black (blank) bitmap? Using DrawLine would be faster than SetPixel, and not doing it at all would be faster still. After all, you are running through all those iterations of the loop to create the exact same bitmap over and over. Create it once in something like MS Paint, Paint.NET, or your bitmap editor of choice, add that bitmap as a resoucre, and skip the need to ever draw that portion.

[vinniewryan]

Actually it draws a 30 x 30 pixel square. In this example it sets the color of each pixel to 255. I replaced the 255,255,255 with variables that signify rgb values. It's like a mini 30x30 pixel tv for my tiny 30x30 optical mouse sensor camera.

[Shaggy Hiker]

Ah, ok. Setting it to all one pixel made it appear to be a big waste of time, but for what you are actually doing, you don't have much choice.

You do have SOME choice, though, so how's it working? If the performance isn't what you want, you might consider doing some custom buffering. You are drawing directly onto the visible screen. Most games draw onto an offscreen bitmap and flip that to the screen once completed. If your performance isn't all you'd like, that's probably the route to follow.

[vinniewryan]

It's coming along quite nicely. With the generous help of you and others on this forum I've been able to achieve great success in a little amount of time. My Com port is receiving pixel data, sending it to a buffer (which is for now a text box) - then retrieving numbers and commands from the buffer and setting pixel values of the bitmap accordingly. Everything is working. Now I need to speed things up. I'll take your advice and try drawing to an external bitmap. I also need to figure out a better buffer than the slow rich text box. I figured just adding the characters to a string would do the trick but myString &= textString seems to replace myString rather than adding the contents of textString to it.

Also, I found that doonce was never executing because it was declared within a protected sub. Declaring it in the very top of the code before any subroutines fixed that problem.

[Shaggy Hiker]

ANYTHING would be a better buffer than a control. If the control is visible, then every time you add a byte to that buffer, you get a redraw of the control. Total waste of time.

Adding characters to a string should work....but don't do that anyways. Still, myString &=textString should not replace myString, so something really odd is going on there. You might want to investigate that further, but only for your information. Ultimately, you really aren't adding to the string anyways. Whenever you concatenate two strings, a new string of the combined size is created, and both existing strings are copied in there. So you are throwing out and replacing, each time. Not so good.

Depending on what data you are using, take a look at Queue(of T), or possibly a StringBuilder object. The Queue is the obvious choice, as you can stuff things on, and pop things off, as you please. It would be efficient, too, though depending on what you pop off the queue, and whether you need to search it, there may be more efficient collections. The StringBuilder was added to be more efficient than concatenation because of the cost I mentioned in that first paragraph. The Append method of that one would work the way you wanted with &=, but it would be more efficient.

Another option would be a simple List (of T). This might be more efficient for searching than the Queue, but you'd have to take care to keep things in order with the List, which the Queue would do for you.

Finally, when it comes to boosting performance, you could look into profiling. That's a whole topic on its own, but I found that I wanted to just answer a simple question, so I wrote up a little profiler class that I could put into any project. It's over in the .NET CodeBank if you're interested in it. You use it by putting tags at places through a process, then run the process. At the point you designate, it tells you how long it took to get from each tag to that point. The source is all there, and there isn't much to it, so you can modify to suit, too.

[vinniewryan]

hmm, I'll look into these functions.

Queue seems to be suitable. Does this look correct?

'text = serialPort1.readexisting string
dim c as new char
Dim queueList As New Queue
queueList.Enqueue(text)

if(queueList.length > 0)
    c = queueList.Dequeue() 'this will remove the oldest char from queue making its length -= 1?
end if

[Shaggy Hiker]

Mostly, you probably need to supply a type for Queue, though. It seems like strings might work best:

New Queue(of String)

though you could use characters or bytes. I would also use .Count rather than .Length, though I doubt it matters any. Both probably work about the same way.

[vinniewryan]

Ok, I'll give it a try tonight and post the result tomorrow.

Dim queueList As New Queue(of String)

[Shaggy Hiker]

queueList? Really? Isn't queue hard enough to type as it is? I'm a pretty good typist, yet I screw that word up more than just about any word of a similar length. You've gone and used it as a variable name AND stuck something on the end of it that happens to be the name of a different type of collection entirely. I'd use the letter Q, and precede it with something easier to spell.

Of course, that's not a real objection. I'm just on drugs....well, antibiotics, actually, due to an illness, but it has led to a bit of flippancy.

[vinniewryan]

Dim Q As New Queue(of String)

There, happy? :P

I didn't get a chance to test it last night, my restlessness got the better of me. Looks like today is D-day and I'm attacking this form application with full force!

com port -> 
Q(as string) -> 
c(as char) = queueList.Dequeue() -> 
if(isnumeric(c)) Then 
    bm.SetPixel() 
ELSE 
    refresh everything. 
BAM.

[vinniewryan]

Turns out, this method is faster than any I've tried so far:

        Dim c As Char
        Dim returnValue As Integer

        returnValue = SerialPort1.ReadByte
        c = ChrW(returnValue)

Obviously I'm doing something seriously wrong here not having a buffer, the serial port seems to be buffering all by itself?

EDIT: c = ChrW(SerialPort1.ReadByte)
EDIT:EDIT: Well I just answered my own question. The serial port buffer fills up if I don't use SerialPort1.DiscardInBuffer() every once in a while.

Next question:

My program uses 3 forms.
frmMain - has a button that opens another form called frmVideo
frmVideo - has a button that opens another form called frmConfig
frmVideo has a public variable called doonce. When doonce = 1, a message box is displayed.

When I use frmVideo.doonce = 1 from the frmMain form, nothing happens however:
When I use frmVideo.doonce = 1 from the frmConfig form, it displays the message.

Why would frmVideo only receive a command from the form it opened and not the form that opened it?

[Shaggy Hiker]

A couple possible issues:

1) You may not be working with the same variable each time. frmVideo sounds like the class name. It is also the name of the default instance. If, however, the frmVideo instance that is opened by frmMain is not the default instance, then you may be changing the doonce variable in the default instance, but displaying a different instance. Default instances cause all kinds of confusion and are therefore essentially evil. However, since you were describing a scenario, it isn't clear whether this even applies.

2) Changing doone doesn't seem like it should do anything, on it's own. Unless you have changed how that variable works. Something else has to cause the frmVideo to repaint before the change to the variable has any impact. Is it possible that frmConfig causes that repaint but frmMain does not? I certainly don't see why frmMain would cause a repaint of a child form, but then again, I don't see why frmConfig would cause a paint, either.


As for the buffer, you have indeed answered your question. One thing that you might consider would be to have a single thread reading those bytes as fast as it can, and stuffing each onto a queue. The queue could then be read at some other time by a different thread. Of course, this is a bit hard to justify, as the serial port is buffering bytes, and all you'd be doing is shifting them from the serial port queue to your own queue. The only advantage would be that you have little control over the serial port queue other than to read it or flush it. Still, there may well be no advantage to moving to an internal queue if you are content with discarding the buffer an losing those pending bytes periodically.

[vinniewryan]

Well with a little 2-way communication I think I can resolve the buffer problem. If the buffer size is anywhere near its 4096 byte limit, I'll clear the buffer and tell the micro to stop sending until everything catches up.

I'll look into the other thing, default instance and whatnot. Thanks again, I'm finally seeing FAST pixels

[vinniewryan]

Well everything is working perfectly, up to the OnPaint event. From tutorials online I understand that this is the correct setup for onpaint:

Protected Overrides Sub OnPaint( _
       ByVal e As System.Windows.Forms.PaintEventArgs)
        vWidth = (pixX * vSize)
        vHeight = (pixY * vSize)
        posX = ((Me.Width / 2) - (vWidth / 2))
        posY = ((Me.Height / 2) - (vHeight / 2))

        Dim bm As New Bitmap(vWidth, vHeight)
        Graphics.FromImage(bm).Clear(Color.Black)

        While (d = 1)
            f = pixArray.Count

            If (pixcurrent < f) Then
                pixcurrent += 1
                c = pixArray(pixcurrent) 'pixArray is an array of integers that 
            End If                             'represent b/w pixel values (0 - 255)

            If currentpixY < vHeight Then
                If currentpixX < vWidth Then
                    If (vsYCounter < vSize) Then
                        If vsXCounter < vSize Then
                            cpx = currentpixX + vsXCounter
                            cpy = currentpixY + vsYCounter
                            bm.SetPixel(cpx, cpy, Color.FromArgb(c, c, c))
                            vsXCounter += 1
                        Else
                            vsYCounter += 1
                            vsXCounter = 0
                        End If
                    Else
                        vsYCounter = 0
                        currentpixX += vSize
                    End If
                Else
                    currentpixY += vSize
                    currentpixX = 0
                End If
            Else
                e.Graphics.DrawImage(bm, posX, posY)
                currentpixY = 0
                doonce = 1
                d = 0
            End If
        End While
    End Sub

You mentioned that I should NOT put the loop inside of the onPaint thread. My problem is that if I try to move the loop out of this thread and place the declaration for bm bitmap in the main form, it tells me the following:

Error 1 'e' is not declared. It may be inaccessible due to its protection level.

[vinniewryan]

by the way, I get this error when I call e.Graphics.DrawImage(bm, posX, posY). If I leave this line in the OnPaint sub, then when bm.SetPixel is called, it tells me the width of bm is < 1.

[Shaggy Hiker]

The signature is wrong. There's always a "sender As Object" argument prior to the e argument. Was that just an oversight?

I don't see why bm would have a width less than 1 unless it is either 0 or negative. However, you calculate the width using a couple variables that I don't see, so perhaps one of them is incorrect? You could put a breakpoint on that line, then go look at the width that was used to create the bitmap.

When I said that the loop shouldn't be in Paint, I was misunderstanding your goals. With my current understanding of what you are doing, I don't think there is a better way than having the loop right where you do. You really want that graphics object that comes with the e argument. I don't know whether or not there is an acceptable alternative to getting that graphics object. Besides, the bitmap is liable to be changing every time you paint, and so painting makes total sense. I was initially thinking that you weren't displaying the changes the way you are.

[vinniewryan]

That was an oversight, thanks for catching it! I found that bm has a width of < 1 because at the time I try to reference it, it hasn't yet been created. Refresh() isn't working. I need some way to force the OnPaint function to run and update before I reference bm.

The problem with nesting the loop inside of OnPaint is that my variables don't seem to update. In fact, OnPaint seems to completely ignore the lines before the loop. I'm trying to understand who this function runs, but at this point I'm already trying { imagebox1.image = bm } instead. it's much slower but seems I can update it with a simple command.

the missing lines were just identifiers:

    Public vWidth As Integer
    Public vHeight As Integer
    Dim posX As Int16'width
    Dim posY As Int16 'height
    Public vSize = 4
    Dim vsXCounter
    Dim vsYCounter
    Dim serText As Int16
    Public c = 255 'number from sensor as contrast value 0~255
    Dim j As Int16 = 0
    Dim currentpixX = 0
    Dim currentpixY = 0
    Dim cpx = 1
    Dim cpy = 1
    Public doonce = 0
    Dim t = 0
    Public pixX = 30
    Public pixY = 30
    Public p = 0
    Dim n = 0
    Public pixArray As New ArrayList()
    Dim pixcurrent = 0
    'Public d = 0
    Dim f = 0
    Public h = 0

[Shaggy Hiker]

Technically, bm doesn't have to be declared inside OnPaint. You could move that to form scope and set it up when the form loads. You just want to use it inside OnPaint. However, that's probably irrelevant based on the other things you said.

All of those lines should run before the loop. If they are inside the OnPaint (in which case none should be Public), they will run first because of the assignments (=). If they are other variables, they will run before the constructor even begins. So all of those should have run, and you should be able to see them run by putting a breakpoint on them, yet you say that they don't. That is very peculiar behavior indeed. Any more data on that? What happens if you put a breakpoint prior to the loop?

By the way, you shouldn't be using an ArrayList for anything. Those were of use up through VS2003, but since that time, they have been totally replaced. The object still remains for legacy reasons, but is totally deprecated in favor of the List (of T). The problem was that ArrayList is not strongly typed. It's a list of Object, and you can put anything into it. The generics, including List (of T), were added to provide strongly-typed alternatives, which are more efficient.

As another note, do you have Option Strict ON? That's something that gets overlooked, but for what you are doing, you really want it. It forces explicit conversions rather than implicit conversions, and implicit conversions are slower, so Option Strict will keep any less efficient constructs from sneeking by.

[vinniewryan]

wow adding option stric gave me all kinds of things to fix. Thanks again, I reverted everything back to using my onpaint code. I'll update when I can

[Shaggy Hiker]

In one test I did (by accident) code speed can increase by up to 50&#37; by fixing all those things. Most of the problems will be implicit conversions, which often cause no trouble, but are never as fast as explicit conversions, despite the fact that you have to type more characters to use explicit conversions. That's where the bulk of the speed increase comes from. The other thing that you might find is some fixes to bugs that you haven't even encountered, yet.

[vinniewryan]

this is literally driving me crazy! I don't get it and nothing I've searched has answered the simple question of why a simple code like the one below doesn't update the picture box:

Public Class Form5
    Public Sub l(ByVal state As Integer)

        Dim bm As New Bitmap(100, 100)
        Dim c As Integer

        While (state = 1)
            If c < 255 Then
                Graphics.FromImage(bm).Clear(Color.FromArgb(c, c, c))
                PictureBox1.Image = bm 'never updates
                PictureBox1.Invalidate()
                Me.Update()
                c += 1
                lbl1.Text = c 'never updates

            Else
                c = 0
                state = 0
                MsgBox("Finished") 'message box displays, but label and pix box don't update
            End If
        End While

    End Sub

End Class

When I use "form5.l(1)", the code runs all the way to the end, it sets all variables correctly BUT the visuals 'picturebox1 and lbl1' never update. Why? I've invalidated the picturebox to be redrawn, I've even tried adding me.Refresh() after doing so and still no luck. The only way the picture box will update is if I add and click a button.