Support Forums

I just spent hours today working on this bit of code, and I think it's worth it lol. Everything is virtually perfect the way it's been fine tweaked now I believe. I spent hours on getting this to work...

It's a bit of Process and Thread Management combined with Priorities, Affinity, Thread privillege "sharing", and the outcome creates a fully functional bit of workers that all perform at once and don't hardly interfere with the UI regardless of whether or not they use or modify controls on the main thread's form.

Preview:
[Image: UDvgH.gif]

*NEW

Edit: There were no glitches at all in the live preview, the one in here is because of my Camtasia studio.

This is so epic, nice freraking job man. So sick!

I will be demonstrating the source of this soon as well. I'm just working on implementing this into an existing application that I have to improve performance if i'm going to multi-thread and persist UI modifications on various threads.

That button click shown in the GIF (while the label is still counting) is actually ignored, which is what I was trying to demonstrate there, but unfortunately I can't really do that.

This is to prevent multiple threads doing the same function from being started at the same time while a pre-existing thread is already functional.

The way this concept works:

-A thread is started (counts the label control text value upwards)
-The thread alternates it's process using the breaks in between (when it's not updating the label; fraction of a second) to update the UI, keeping it functional
-The thread goes back to updating the label which takes precedence
-Repeat

-While thread is still functional, disable closing of form or starting a new thread which does the same thing (count the label text value upwards)

In the end you're utilizing the full potential of your thread and avoiding wait times that do nothing. And you can use threads that update the UI without it's heavy loaded process noticeably freezing the UI at all.

THE BIG DIFFERENCE HERE: This doesn't use a control timer, and the updates are from a full process chunked out into smaller parts. Resuming the original process instead of starting a new one each time.

Code:
Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load

        Label1.Text = "0"

    End Sub

    Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click

        Timer1.Start()

    End Sub

    Private Sub Timer1_Tick(sender As System.Object, e As System.EventArgs) Handles Timer1.Tick

        Label1.Text = CStr(CInt(Label1.Text) + 1)

    End Sub

You can do that, but this is more of a new process each time in essence.

For example, say you want to load all the values of an array into a textbox. The method of using a timer like that may not help you, as a timer tick is initiated as ONE process each time, so you may end up with it loading the array into the textbox each time the timer ticks.

I'm having a hard time explaining this, but the way the method works above from what I posted, you build onto an already existing process.

It's like having a construction worker, build a house, and giving them a lunch break to replenish. That lunch break time is essentially needed to update the UI, but you're not building a house each time, you're building on the same house in chunks, and allowing something else to happen in between the initial start and end process.

That's sick! Any chance you will be releasing the code?

Here's an update of it alternating the update for each Label and the UI itself on a single new thread separate from the UI's main thread.

[Image: IjvgO.gif]

*Does not use the Thread.Abort() method - Calls for thread completion*

Downloadable Preview & Source Available Here: http://tech.reboot.pro/showthread.php?tid=2109

that could come in useful, good work

The idea here I was trying to achieve was alternate processing, kind of the concept behind a mutex but much simpler. Although mutex is used for a different purpose, not necessarily alternating, but when it's required it's like a queue manager telling when to wait for another to be released..

Multi-threading to a higher degree would have been an option, or even CPU affinity with parallel programming. Running each task on a new available CPU, although this would differ from system to system depending on the number of cores, so it's questionable until you see how many are available to work with. That's a bitwise calculation btw... I've done it before with another project I finished a while back.

Damn dude, great idea.

You're talented.

AceInfinity

Bill Nye The Science Guy

AceInfinity

Intellect

AceInfinity

kpn37z

AceInfinity

Kewlz