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

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:

Code:

---

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.

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

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.

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

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()

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.

cool :)

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).

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.

Quote:

---

Originally Posted by 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.

---

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.

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

Code:

---

OnPaint.Set.Pixel()

---

??

Code:

---

or bm.Set.Pixel()

---

'where bm is the bitmap object

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

Code:

---

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.

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.

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 :]

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.

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)

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

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.

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

Code:

---


    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.

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)

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.

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.

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.

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. :D

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.

hmm, I'll look into these functions.

Queue seems to be suitable. Does this look correct?

Code:

---

'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

---

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.

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

Dim queueList As New Queue(of String)

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.

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!

Code:

---

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

---

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

Code:

---

        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?

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.

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 :D

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

Code:

---

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.

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.

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.

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:

Code:

---

    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

---

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.

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

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.

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:

Code:

---

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.

"form5.state = 1" troubles me. Form5 sounds like a default instance, as nobody would name a variable that way on their own. Setting something for the default instance will only update the default instance. It isn't clear that you are showing the default instance, so it may be the case, as suggested in #31, that you are setting the variable on the default instance, but displaying a different instance, which would result in exactly the behavior you are seeing: One instance updates, but that one isn't visible. The visible instance isn't updated.

Ah, my bad. The line isn't form5.state=1, it's 'form5.l(1)' which should run the subroutine l and update everything within that form.

I edited the post so it's correct now.

I'm not quite sure how to stray from the default instance. I'll look into that. I just need a simple function that receives a variable, then updates the picture box. I keep running into this problem where it won't update the picture box, or g.graphics. The variables are updating and the code is running all the way through, but no visual updates take place.

the code I posted is the complete code for form5. It's a blank form with a picture box, nothing else.

have you tried just refreshing the thing that needs refreshing

i used to do that a lot!

picturebox1.refresh

here to suggest

Yeah I tried that. It doesn't seem to do anything. My graphics are still hidden.

The code of Form5 is one thing, but the key is how you display that form. The best way to do it would look something like this:

Code:

---

Dim myForm as New Form5

myForm.Show
or
myForm.ShowDialog

---

If that is how you are showing the form, then the problem is due to defaults. After all, Form5 is a type of form, but it is also a specific instance of the form. That's what the defaults are about. A specific instance is quietly created, and given the same name as the class type, which has caused mayhem ever since it was introduced back in VS2005. Your code is going to do something to the default instance, but if you aren't showing the default instance (as my example is not), then you are updating a form that isn't visible, while NOT updating a form that IS visible. In other words, the wrong form is being updated.

You are updating the default instance, but it is not clear whether you are showing the default instance. I hate the default instances. They do nothing more than cause confusion. They don't even behave exactly the same as other instances, though the differences are subtle. If you are using a line like form5.Show, then I would suggest changing things around to use non-default instances.

If you were using my example, the call you would have to make would be to:

myForm.l(1) (or whatever that sub name is).

That makes so much sense. So when I use Form5.Show, it's showing Form5 as it was when that line of code was executed. It's showing the default instance. I get it now.

So how do I show the updated instance? How do I get form5 to show itself updated?

For instance, if I want the picture box to refresh every time my main form receives the letter P on the com port, then would I use

if(serialcharacter = "P") Then
Form5.l(1)
Form5.Show

this doesn't seem right because this would mean I have to close the form in every frame as well, otherwise it will open up infinite instances of Form5.

EDIT: By the way, the form appears when I click a button that looks like this:

Code:

---

Private Sub Button1_Click_1(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Form5.Show()
    End Sub

---

You don't quite get it, but with that last snippet, it is clear that you are ONLY showing the default instance.

When you create an object:

Dim myObj As New SomeObject

then myObj is a variable that holds the new SomeObject that was just created (roughly speaking). You Always have to create a new instance of a class to use it. This is just as true of forms as for other types of classes, so you have to have a New Form5 somewhere....but you don't. The reason is that VS is creating an instance of Form5, and calling that instance Form5. In other words, hidden somewhere that you don't see is a line like this:

Public Form5 As New Form5

That actual line isn't really there. Somebody on here once posted the actual code that does this, and it doesn't look exactly like that. For instance, the default instance isn't there if you don't use it, but is just created on demand. Still, as far as you are concerned, that line is there. Because of that, when you call:

Form5.Show, it works. If that line wasn't there, then Form5 would be an undeclared variable, and you'd get an exception when you tried that line. However, the variable Form5 is being quietly, and secretly, declared for you such that it is there when you go to show it. That may seem useful, but it mostly sucks. However, it doesn't seem relevant, in this case, because you are showing the default instance in that button click event. It appears that you never have any line like:

Code:

---

Dim <some name> As New Form5

anywhere, so you are ONLY working with the default instance. That should work. All that I was saying isn't relevant. The default instance isn't a default display, it is an instance of the class. The class is responsible for drawing itself. You could easily have multiple instances:

Dim A as New Form5
A.Show 'Shows one instance of Form5
Dim B as New Form5
B.Show 'Shows another instance of Form5

A.l(1) 'This should update just one of the two forms on the screen.

---

That's what I thought you were doing. I thought that you had something like this:

Code:

---

Dim A as New Form5
A.Show 'Show instance called A
Form5.l(1) 'Update default instance

---

You aren't doing that, because you are only showing the default instance, and only updating the default instance. I hate default instances, but what you have shown should not have any problem due to default instances.

I did notice that you had Me.Update. The term, I believe, is Me.Refresh, and you should only need to refresh the picturebox, but refreshing the whole thing should work, too (though not quite as quickly, since you are redrawing EVERYTHING).

Can't look at the code now, either, because it's on the last page. Just a quirk of the forums.

Ok, now that I've taken a second look at the code, I'd suggest a little test:

Comment out all the code dealing with the picturebox. Those are weird and potentially time consuming. The first thing to look at is that label, which is pretty simple, so set aside the rest. Right now, your loop will run 255 times before state is set to 0. That's fine, but you might consider running it only once or twice for testing purposes. The key is to see whether or not the label updates if there isn't anything else going on in there.

ok so I made a few changes. In my main code, for the button I changed it to:

Code:

---

Private Sub Button1_Click_1(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim frm5 As New Form5
        frm5.Show()
End Sub

---

The frm5 code is as follows:

Code:

---

Public Class Form5

    Public Sub l(ByVal state As Integer)

        While (state = 1)
                lbl1.Text = "BAM" 'never updates
                MsgBox("Finished") 'message box displays, but label and pix box don't update
                state = 0
        End While
    End Sub
End Class

---

Still no update. I tried using Form5.l(1) and frm5.l(1) - after making the necessary changes.. No luck with either.

How were you able to call that sub? With the change you made to the button, you are now showing an instance of Form5 called frm5, but it would not be accessible from anywhere other than that button sub, because frm5 is a local variable to that sub. To call the public sub, you'd have to have the line

frm5.l(1)

but the compiler will say that frm5 doesn't exist if that line is anywhere outside of the button sub. If you called Form5.l(1) instead, then you called the sub on the default instance, though you were showing the instance called frm5.

EDIT: I see that you called it frm5.l(1) after making whatever necessary changes. That would be the right test. If the label still isn't updating, then something very strange is happening.

Yes, you caught that correctly.

after one more test, I made this change to my main form

Dim frm5 As New Form5
frm5.Show()
frm5.l(1)

This opens up the new form and the label shows "BAM" as it should, but when I click Ok on the message box, the whole window becomes invalid. I can't close it, other windows leave a trail when I move them around above it.

Does this seem correct? The problem is that I need form5 to update itself every time state = 1. Otherwise I would constantly have to be opening 'show' and closing/disposing of the form to get it to display the constantly changing picture box. This seems messy?

I've had a little more success. I now have the picture box updating and the label, in realtime. I mean I can see the label count from 0 to 255 and the picture box fade from black to white.

This is an improvement, but this is only one frame. How would I go about doing this 30 times per second?

If I create a new form instance each time (frm5 = new Form5, frm5.show), it will pop up the new form in a different position on the screen every time - And, I can't move the new form window around. It's stuck and doesn't accept close, minimize, or restore mouse commands..

It seems this form is invalid as soon as it's created.

It sounds to me like that form is spending so much time doing something that it can't respond well to mouse inputs, or any other kind of input. The bit about other windows leaving tracks suggests that the initial window doesn't have time to redraw whenever it is being invalidated.

As for redrawing that fast, there probably are limits to what you can do with GDI+, though from what you have shown, I don't think you are there. I'm no expert when it comes to drawing, but I do have one program that forms and draws a series of bitmaps onto the screen. The calculations for the bitmaps are kind of complicated, though perhaps not as complicated as your pixel by pixel drawing. After a bit of work, I got the drawing down to about 10ms, which would mean 100 fps, except that I am doing up to 100 of these drawings each time, or 1 fps. Ultimately, I had to change the algorithm so that I was only ever drawing one or two, rather than the full set, each time around. You, to, may be up against a limit on GDI+. You might use the lightweight profiler class I have over in the .NET CodeBank to take a look at your actual timing, which might show you something...or not.

Thanks Shaggy for all of your help, after reading through your posts and making suttle changes here and there I found my mistake.

I was doing this:

Code:

---

Private Sub Button1_Click_1(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        frmVid = New frmVideo
        frmVid.Show()
    End Sub

---

-Which is perfectly ok, until I tried refreshing frmVid using frmVid.Show() again, when refreshing wasn't needed because it's not the default instance anymore.

frmVid.display(1) now works perfectly and the bitmap/picture box refreshes every time.

Thanks again. It's exciting to have complete control of this tiny camera now, and after this feat I'm all pumped up with that 'Now... I can program anything' mentality. Until the next hurdle :P

Cheers!

Good show. Mark this thread resolved and start a new one with any new questions. I find that after threads get to a certain size, they don't get the eyeballs anymore, so you don't get new views on the matter.

Agreed - and thanks again.