Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Visual Basic
  4. TopMost isnt working for me

TopMost isnt working for me

Scheduled Pinned Locked Moved Visual Basic
helpannouncement
7 Posts 5 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • U Offline
    U Offline
    uk_nbb
    wrote on last edited by
    #1

    I have a program that I have written that uses its main form to show buttons which show the status of devices. These button have their own class (inherting the button class) and are run as their own threads and can update themselves as required. What I want to do, is to make the form become the TopMost window when one of the buttons indicates an error condition. I can make the button threads modify a master variable of the form, and that works. But when I then also try to make the form TopMost (TopMost=True) (actioned by a button thread) is does not get remembered. E.G if a button thread calls the main forms subroutine :- Public Sub attention() SyncLock myObjLock If need_attention = False Then need_attention = True TopMost = True End If End SyncLock End Sub need_attention gets updated to False but TopMost never happens. If I call this from the main form routines it seems to work, just not when a thread calls the routine. I'm not sure if I'm missing something simple, hopefully I am. Please help Thanks Nigel

    C C L 3 Replies Last reply
    0
    • U uk_nbb

      I have a program that I have written that uses its main form to show buttons which show the status of devices. These button have their own class (inherting the button class) and are run as their own threads and can update themselves as required. What I want to do, is to make the form become the TopMost window when one of the buttons indicates an error condition. I can make the button threads modify a master variable of the form, and that works. But when I then also try to make the form TopMost (TopMost=True) (actioned by a button thread) is does not get remembered. E.G if a button thread calls the main forms subroutine :- Public Sub attention() SyncLock myObjLock If need_attention = False Then need_attention = True TopMost = True End If End SyncLock End Sub need_attention gets updated to False but TopMost never happens. If I call this from the main form routines it seems to work, just not when a thread calls the routine. I'm not sure if I'm missing something simple, hopefully I am. Please help Thanks Nigel

      C Offline
      C Offline
      Christian Graus
      wrote on last edited by
      #2

      Have you set a breakpoint to make sure the TopMost call occurs ?

      Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )

      U 1 Reply Last reply
      0
      • U uk_nbb

        I have a program that I have written that uses its main form to show buttons which show the status of devices. These button have their own class (inherting the button class) and are run as their own threads and can update themselves as required. What I want to do, is to make the form become the TopMost window when one of the buttons indicates an error condition. I can make the button threads modify a master variable of the form, and that works. But when I then also try to make the form TopMost (TopMost=True) (actioned by a button thread) is does not get remembered. E.G if a button thread calls the main forms subroutine :- Public Sub attention() SyncLock myObjLock If need_attention = False Then need_attention = True TopMost = True End If End SyncLock End Sub need_attention gets updated to False but TopMost never happens. If I call this from the main form routines it seems to work, just not when a thread calls the routine. I'm not sure if I'm missing something simple, hopefully I am. Please help Thanks Nigel

        C Offline
        C Offline
        cutequencher
        wrote on last edited by
        #3

        try to use mdiparent

        1 Reply Last reply
        0
        • U uk_nbb

          I have a program that I have written that uses its main form to show buttons which show the status of devices. These button have their own class (inherting the button class) and are run as their own threads and can update themselves as required. What I want to do, is to make the form become the TopMost window when one of the buttons indicates an error condition. I can make the button threads modify a master variable of the form, and that works. But when I then also try to make the form TopMost (TopMost=True) (actioned by a button thread) is does not get remembered. E.G if a button thread calls the main forms subroutine :- Public Sub attention() SyncLock myObjLock If need_attention = False Then need_attention = True TopMost = True End If End SyncLock End Sub need_attention gets updated to False but TopMost never happens. If I call this from the main form routines it seems to work, just not when a thread calls the routine. I'm not sure if I'm missing something simple, hopefully I am. Please help Thanks Nigel

          L Offline
          L Offline
          Luc Pattyn
          wrote on last edited by
          #4

          uk_nbb wrote:

          and are run as their own threads

          I am not sure what you are saying here, are you having some other thread create and handle a Button ? All Controls require they be touched only by the thread that created them, which in practice means everything gets created and touched by the main thread (aka GUI thread only), since thats where your first Form gets created, and normally everything in one way or another connects to it. There are a few properties/methods that dont have to obey this rule; mainly InvokeRequired and Invoke() and its exactly these that you must use to let another thread do something to a Control it did not create. If you dont follow the rules here, on old .NET (prior to 2.0) it may or may not work, typically it will suddenly ignore you or freeze, show a white menu bar, things like that. Since 2.0 it will throw an InvalidOperationException except when you have set CheckForIllegalCrossThreadCalls=false, which is considered bad practice and brings you back to the 1.x behavior. Hope this helps. :)

          Luc Pattyn [My Articles] [Forum Guidelines]

          U 1 Reply Last reply
          0
          • C Christian Graus

            Have you set a breakpoint to make sure the TopMost call occurs ?

            Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )

            U Offline
            U Offline
            uk_nbb
            wrote on last edited by
            #5

            The TopMost call gets called and is set to true. But when I set a breakpoint further on when something else happens and I look at the TopMost value, it is False and so the setting is never held. I never set it back to False so it can't be holding its value (well its not being set properly I guess). Its confusing !!! Nigel

            D 1 Reply Last reply
            0
            • L Luc Pattyn

              uk_nbb wrote:

              and are run as their own threads

              I am not sure what you are saying here, are you having some other thread create and handle a Button ? All Controls require they be touched only by the thread that created them, which in practice means everything gets created and touched by the main thread (aka GUI thread only), since thats where your first Form gets created, and normally everything in one way or another connects to it. There are a few properties/methods that dont have to obey this rule; mainly InvokeRequired and Invoke() and its exactly these that you must use to let another thread do something to a Control it did not create. If you dont follow the rules here, on old .NET (prior to 2.0) it may or may not work, typically it will suddenly ignore you or freeze, show a white menu bar, things like that. Since 2.0 it will throw an InvalidOperationException except when you have set CheckForIllegalCrossThreadCalls=false, which is considered bad practice and brings you back to the 1.x behavior. Hope this helps. :)

              Luc Pattyn [My Articles] [Forum Guidelines]

              U Offline
              U Offline
              uk_nbb
              wrote on last edited by
              #6

              I think Invoke() may be my missing link. I will read all about it and have a go. Thanks Nigel

              1 Reply Last reply
              0
              • U uk_nbb

                The TopMost call gets called and is set to true. But when I set a breakpoint further on when something else happens and I look at the TopMost value, it is False and so the setting is never held. I never set it back to False so it can't be holding its value (well its not being set properly I guess). Its confusing !!! Nigel

                D Offline
                D Offline
                Dave Kreskowiak
                wrote on last edited by
                #7

                Well, it works and it sticks. The only three things that can change that are: 1: You change it back to False. 2: You create a new instance of your form somewhere along the way and assign it to the same variable, thus giving the appearance that it didn't stick. 3: Some other form set TopMost to True somewhere else in your app.

                A guide to posting questions on CodeProject[^]
                Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
                     2006, 2007

                1 Reply Last reply
                0
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • World
                • Users
                • Groups