CodingSup3rnatur@l-360's Profile User Rating: *****

Reputation: 982 Master
Group:
Mentors
Active Posts:
969 (0.75 per day)
Joined:
30-September 10
Profile Views:
61,512
Last Active:
User is offline Today, 11:54 AM
Currently:
Offline

Previous Fields

Country:
GB
OS Preference:
Windows
Favorite Browser:
Chrome
Favorite Processor:
Intel
Favorite Gaming Platform:
XBox
Your Car:
Who Cares
Dream Kudos:
425
Expert In:
C#

Latest Visitors

Icon   CodingSup3rnatur@l-360 My status

Posts I've Made

  1. In Topic: Problems abt inputing ln(x) function in vb 2010

    Posted 16 Feb 2014

    If you mean you want to find the natural logarithm (often written as ln x) of a number, you can use Math.Log().

    If you mean you want to implement such a function yourself, yes, you can do that too.

    Otherwise, you will have to clarify what you mean.
  2. In Topic: Custom Form Startup

    Posted 30 Jan 2014

    The cleanest way to do this (in my opinion) is probably to ditch the application framework VB provides, and role your own Main() method. That way, you have complete control over which form to use as the startup form.

    The general steps to do this are:

    1) In the 'Application' section of the project settings, untick 'Enable Application Framework' and change the 'Startup Object' to 'Sub Main()'. This will probably create an error saying something like 'Sub Main() was not found in <project name>', but don't worry.

    2) Create a new class called something like 'Startup' (the name isn't relevant), and in that class put a shared method called Main(), and decorate it with the STAThreadAttribute. EDIT: You should also add a call to Application.EnableVisualStyles() as the first line in Main().


    That Main() method is the entry point of your application, and will be the first method called in your application. It is always there, but is usually quite well hidden by default in VB.NET. You now have access to it, and therefore have complete control over your application startup.

    To do what you want, you could write your Startup class like this, for example:

    Public Class Startup
        <STAThread()>
        Shared Sub Main()
            Application.EnableVisualStyles()
    
            Application.Run(CreateStartupForm())
        End Sub
    
        Private Shared Function CreateStartupForm() As Form
            If My.Settings.ShowForm1 Then
                Return New Form1()
            Else
                Return New Form2()
            End If
        End Function
    End Class
    
    



    It is worth noting that by disabling the 'Application Framework', you do lose some things that VB would normally automatically do for you, like saving settings on application exit. Although some of these features can be very useful at times, they are also all very easy to implement yourself, and I personally like having absolute control over what my application does, and when it does it.
  3. In Topic: What's The Deal With Multi-Threading And Background Workers In WPF

    Posted 31 Dec 2013

    Quote

    So when you use a background thread it's still using just ONE thread correct me if I'm wrong to carry out a calculation or operation.


    If you start one extra thread, then only one extra thread will be used, yes. If you meant to say background worker, rather than background thread, then your statement is still correct. The BackgroundWorker class grabs one thread from the thread pool, and executes your work on that thread.

    Quote

    Okay when you use these options on machines like mine which has an i7 processor this doesn't necessarily mean the calculations will go faster does it?


    True. Parallelizing a section of code won't necessarily mean that it will complete faster. Whether or not you see any speed increases, and the extent of any speed increase, will depend on a wide range of factors. Some key factors often include:

    • The ratio of the number of I/O bound operations to the number of CPU bound operations in the code you are parallelizing.
    • The amount of work the threads have to perform vs the cost of partitioning the work across the threads, and managing the threads at runtime.
    • The amount of contention for shared data/resources that is present between threads.
    • The number of processor cores you have vs the number of threads you are using.


    Basically, when using multiple threads to improve the performance of your code, the only sane advice is to experiment, and let performance measurements guide you towards the best configuration.

    Quote

    See I've seen a lot of confusion on forums etc. that basically state when you use multithreading like that you're gaining more Gigahertz processing calculation power etc. Correct me if I'm wrong but this isn't true?
    ...
    Essentially in one sense using 1 thread for a long calculation generally calculates things just as fast from a sheer processing in Gigahertz clock speed etc. as using parallel threads. Can you explain this whole phenomenon?


    Generally, when you use multiple threads as a means of improving the speed of your code, you are trying to use the available processing resources more efficiently, and ensure your code can continue to do this in the event that extra processing resources become available.

    Now, the clock speed of a CPU will not be increased by using multiple threads. Using multiple threads won't magically make your hardware faster. However, using multiple threads can help you make better use of the hardware you have. Primarily, it can increase CPU utilization, thereby increasing the number of instructions executed per unit time (a measure of throughput).

    For example, if you have N cores and your code is purely CPU bound, you could theoretically improve the speed of your code by a factor of N. This is because each core can execute instructions simultaneously, so by using all cores, you can theoretically increase the throughput by a factor of N.

    Furthermore, a similar idea can apply to single core machines. For example, if you have a single core machine, and two threads, if one thread gets blocked after an I/O request, the other thread can still potentially continue working; making use of an otherwise idle CPU. This could once again lead to increases in throughput over using only one thread.

    In both these examples, the hardware hasn't got faster; we are just making better, more efficient use of the hardware.
  4. In Topic: What's The Deal With Multi-Threading And Background Workers In WPF

    Posted 28 Dec 2013

    Quote

    So another way if you don't want to have to use ANY additional threads like a background worker is to simply use DispatcherPriority and use dispatch right? ... Using a dispatcher CAN keep your UI from freezing during long operations since User interaction with the UI will start taking priority in UI thread


    To a limited extent, yes. However, if you are going to rely on dispatcher priorities and Dispatcher.BeginInvoke() alone to keep the UI responsive during a long running operation, you need to break up the long running task into very small units, none of which are large enough to noticeably freeze the UI when executed. This often isn't going to be desirable, practical, or even possible to do.

    Take a look at this really simple example that hopefully illustrates that dispatcher priorities definitely aren't a replacement for additional threads or traditional asynchronous programming techniques:

    Spoiler


    Now, when the 'Read' button is clicked, ReadAll() might not be be executed immediately if the application is busy doing something else, due to the ApplicationIdle priority I've used. However, when the time does come to execute ReadAll(), the application will still freeze until it completes, because it is all happening on the UI thread.

    You have to remember that the priorities only govern when your work item passed to Dispatcher.BeginInvoke() is allowed to start executing. Once your work item has started executing, it will run to completion without interruption by other work items (blocking the UI thread as it goes), regardless of the priorities involved.

    So, the BackgroundWorker class, the Task Parallel Library, the async/await mechanism and other familiar APIs are still very relevant in WPF, and you'll probably be relying on them far more than dispatcher priorities, because they are simple to use, have built-in support for things like progress reporting and cancellation, will work for almost any long running operation you can throw at them, and, ultimately, will be more reliable in keeping the UI responsive.


    Quote

    I'd nudge you into formalizing that into a tutorial in the WPF section to go along with the other "WPF for WinForms developers" tutorials


    Yeah, I'll give that a go :)
  5. In Topic: What's The Deal With Multi-Threading And Background Workers In WPF

    Posted 27 Dec 2013

    WPF does start out with 2 threads - a render thread and a UI thread - yes. However, the render thread has a very specific, fixed job.

    Very briefly, there are essentially two subsystems in WPF that we are concerned about here - the visual system and the composition system.

    The visual system runs on the UI thread where user input is gathered, events are handled, your code is run etc. This is reasonably familiar (from a high level) from WinForms.

    The composition system runs on the render thread, below the visual system, and is responsible for initiating low level rendering of visual elements and often the animation of elements too Edit: Not sure this is actually true in WPF at the moment.

    The rendering process

    Essentially, what happens is when the visual system needs to render the UI (i.e. when a visual change is made to the UI), it (running on the UI thread) sends the visual changes to the composition system (running on the render thread). At this point, the UI thread is done with the rendering process, and can do other things.

    The composition system now performs various preprocessing like building a tree of visual elements to be rendered, calculating pixels etc.

    The composition system then passes all this data to the rendering engine, which does some low level preprocessing of its own like tessellating shapes etc, and it then passes everything to Direct X which interacts with the display driver.

    Finally, the display driver interacts with the graphics card to performs the rendering of the graphics to the screen using the graphics card.


    Impact of the render thread on application level multithreading

    So, while it is true that the WPF system does separate the rendering process off onto a background thread, this is really a system facility. The render thread has a dedicated purpose in life, and while it potentially brings improvements over the WinForms system, it won't really help you directly in your day to day application level needs.

    For example, if you are loading some large file off disk, your UI will freeze (just like in WinForms) if you don't take measures to keep the UI thread free (whether that be via asynchronous IO or using a dedicated background thread). The UI thread still deals with user input and such like, so if you are blocking that thread, your user will see a frozen application. There is no magic here that will automatically keep your UI responsive for you :)

    WPF vs Winforms

    Really, you can forget about the render thread, since it won't really help you in your day to day multithreading needs. It will happily continue working away in the background doing its thing without you having to think about it.

    So, that leaves you with a single UI thread by default, just like WinForms. Really, WPF isn't that different in terms of its threading model from the application developer's perspective. Sure, it has some nice advancements (like dispatcher priorities, for example), but ultimately:

    • The UI thread is still running a message loop.
    • Controls should only be accessed from the UI thread
    • You still have Invoke() and BeginInvoke() which serve the same purpose as the WinForm equivalents.
    • You still have the BackgroundWorker class and all the other threading/asynchronous mechanisms, all of which continue to work fine in WPF.

My Information

Member Title:
D.I.C Addict
Age:
21 years old
Birthday:
June 11, 1992
Gender:
Location:
United Kingdom
Interests:
Music - Led Zeppelin, Guns N' Roses, AC/DC
Sport
Software Development and Design
Watching Supernatural, The Big Bang Theory, The Walking Dead, Red Dwarf, QI, The Simpsons
Online gaming (Xbox One).
Full Name:
Jason
Years Programming:
3
Programming Languages:
C#, a bit of Actionscript 3.0 ,SQL,Progress4GL, VB.NET. Learning Java, and Assembly/C/C++ when I can.

Contact Information

E-mail:
Click here to e-mail me

Comments

  • (2 Pages)
  • +
  • 1
  • 2
  1. Photo

    strawhat89 Icon

    13 Aug 2012 - 06:01
    A Supernatural fanatic huh?
  2. Photo

    raziel_ Icon

    13 Sep 2011 - 11:31
    Just stalking your profile :P
  3. Photo

    smohd Icon

    03 Jul 2011 - 15:49
    Thank you, and congratulations for Mentor badge. Doing great in C#
  4. Photo

    CodingSup3rnatur@l-360 Icon

    03 Jul 2011 - 08:25
    It's no problem at all, and thanks a lot! I am extremely grateful to be recognised in such a big way!
  5. Photo

    macosxnerd101 Icon

    02 Jul 2011 - 19:19
    Thanks for all your hard work! Welcome to the cyan club!
  6. Photo

    MATTtheSEAHAWK Icon

    07 May 2011 - 12:26
    Congratulations on Expert! Purple nurple :P
  7. Photo

    CodingSup3rnatur@l-360 Icon

    04 May 2011 - 13:32
    Thanks! I couldn't believe it when I saw my name in purple this morning. Thought I'd gone colour blind overnight... It was a very nice surprise :)
  8. Photo

    Curtis Rutland Icon

    04 May 2011 - 06:30
    Hey, grats on the promotion to Expert!
  9. Photo

    ishkabible Icon

    27 Apr 2011 - 13:19
    relatively speaking however, your better. e.g. your skill in C# surpasses my skill in C++ as far as i can tell. you have nearly 1 rep per post o_0. other experts have commented on the extend of your knowledge. keep up the good job :)
  10. Photo

    MATTtheSEAHAWK Icon

    24 Apr 2011 - 14:45
    Thanks! I was working on it until 3:30 am xD
    I was like "I have to finish this!". Are you doing one?
  11. Photo

    ishkabible Icon

    20 Apr 2011 - 19:23
    how on earth did you get that good at programing in a year? f'ing genius...
  12. Photo

    Curtis Rutland Icon

    21 Mar 2011 - 10:42
    Another tutorial added to the Learning C# Series! Keep up the good work!
  13. Photo

    Curtis Rutland Icon

    01 Mar 2011 - 12:04
    Thanks for contributing to the Learning C# Series!
  14. Photo

    CodingSup3rnatur@l-360 Icon

    25 Feb 2011 - 15:54
    @ishkabible - yeah, that looks a lot better. What actually is the limit when you register I wonder... Is there a limit, or could someone technically have a name of like 1000 letters that just swallows the whole page?
  15. Photo

    Neetu sharma Icon

    25 Feb 2011 - 11:52
    hello
  • (2 Pages)
  • +
  • 1
  • 2