9 Replies Latest reply on Mar 26, 2015 7:41 AM by gink01

    Windows 7

    JTG
      I still have a large number of users (200+) using desktop applications built with VB6 and MapObjects 2.1.

      We are planning to move to Windows 7 as our common desktop O/S. 

      Has anyone found any issues running MapObjects apps on Windows 7?
        • RE: Windows 7
          WolfgangE
          > I still have a large number of users (200+) using desktop applications built with VB6 and MapObjects 2.1.

          Here it's 1000+ users, my app is built with VB5 and MapObjects 2.4. :cool:

          >We are planning to move to Windows 7 as our common desktop O/S.
          >
          >Has anyone found any issues running MapObjects apps on Windows 7?

          It generally works fine on Win7, with (so far) one exception that one of our users discovered today: if you move the map content in the MapControl (i.e. the .Pan method is called) and the user holds the mouse button pressed for more than 5-6 seconds, the whole application stops responding forever (problem name: AppHangB1). Strangely enough, this does not happen after application startup as long as the app never loses focus; however, as soon as the dialog containing the map control has lost focus and is then reactivated, the problem can be reproduced reliably. This does not occur in Win 2000 and XP, it does, however, in Vista and Win7. No workaround for that so far ... then again, seems like we only have one user who constantly needs that much time for panning, fortunately. :rolleyes:
          • Windows 7
            WolfgangE
            > I still have a large number of users (200+) using desktop applications built with VB6 and MapObjects 2.1.

            Here it's 1000+ users, my app is built with VB5 and MapObjects 2.4. :cool:

            >We are planning to move to Windows 7 as our common desktop O/S.
            >
            >Has anyone found any issues running MapObjects apps on Windows 7?

            It generally works fine on Win7, with (so far) one exception that one of our users discovered today: if you move the map content in the MapControl (i.e. the .Pan method is called) and the user holds the mouse button pressed for more than 5-6 seconds, the whole application stops responding forever (problem name: AppHangB1). Strangely enough, this does not happen after application startup as long as the app never loses focus; however, as soon as the dialog containing the map control has lost focus and is then reactivated, the problem can be reproduced reliably. This does not occur in Win 2000 and XP, it does, however, in Vista and Win7. No workaround for that so far ... then again, seems like we only have one user who constantly needs that much time for panning, fortunately. :rolleyes:


            More observations ... as above, only Win Vista and higher is concerned.

            First, it's not only the .Pan method that shows this issue. .TrackPolygon, .TrackRectangle and .TrackCircle suffer from the same problem.

            Second, you can reproduce the problem even without waiting for 5 secs. with the mouse button pressed. Just call one the problematic methods, keep the mouse button pressed and hit, for instance, the Windows key; since this fires up the Windows start menu, your app loses focus during panning etc. which immediately triggers Windows to flag your app as unresponsive. After that, you can do whatever you want but your app will keep hanging.

            Obviously, since the methods mentioned above completely take control of the UI thread, the window cannot process any messages at this point. This misleads Windows to assume the app is hanging; now it covers the actual app window with a "ghost window". Looks like this is the reason why the "real" window with the Map on it never receives the MouseUp-message so the method call never returns. However, I'm not sure why this is not a problem in WinXP (which has the window ghosting feature also).

            Anyway, it looks like I've found a good solution. Just call the following function at startup:

            Declare Sub DisableProcessWindowsGhosting Lib "user32" ()
            'see http://msdn.microsoft.com/en-us/library/ms648415.aspx
            'available in WinXP and above


            This makes the window ghosting go away, along with all these MO problems. :)
            1 of 1 people found this helpful
            • Windows 7
              JTG
              Excellent - thanks for all the information.
              • Re: Windows 7
                seckersall
                Wanted to thank you very much for your post - still maintaining a VB6/MOLT2 app and this proved to be a solid and simple fix for a vexing problem.  Thank you again - really appreciate it!

                Anyway, it looks like I've found a good solution. Just call the following function at startup:

                Declare Sub DisableProcessWindowsGhosting Lib "user32" ()
                'see http://msdn.microsoft.com/en-us/library/ms648415.aspx
                'available in WinXP and above


                This makes the window ghosting go away, along with all these MO problems. :)[/QUOTE]
                1 of 1 people found this helpful
                • Re: Windows 7
                  ddresh
                  >Anyway, it looks like I've found a good solution. Just call the following function at startup:

                  Code:
                  Declare Sub DisableProcessWindowsGhosting Lib "user32" ()
                  'see http://msdn.microsoft.com/en-us/library/ms648415.aspx
                  'available in WinXP and above<



                  New to the forum,

                  Thank you. THANK YOU!! This is a great solution to yet another Win 7 snake pit. As others have said I must maintain vb 6.0 apps for a while yet and this issue was a deal breaker until I found this forum!

                  Thanks again,

                  Dan
                  • Re: Windows 7
                    steporritt
                    Not sure if anyone's still reading / replying to this thread, but I'm still supporting a MapObjects VB.Net 1.1 app. I have an issue, which is the bottom level area layer of the map isn't drawing. ie, when a user loads a map, they can see any points placed on the map, any additional geographical boundaries that have been loaded, but not the colour coded default areas of the map. This started on Windows7, but is now happening on WindowsXP (presumably due to a Windows update). Does anyone else have an issue where one layer of the map won't draw? Any help is massively appreciated. Thanks,

                    Stephen
                    • Re: Windows 7
                      jbarry-esristaff
                      Not sure if anyone's still reading / replying to this thread, but I'm still supporting a MapObjects VB.Net 1.1 app. I have an issue, which is the bottom level area layer of the map isn't drawing. ie, when a user loads a map, they can see any points placed on the map, any additional geographical boundaries that have been loaded, but not the colour coded default areas of the map. This started on Windows7, but is now happening on WindowsXP (presumably due to a Windows update). Does anyone else have an issue where one layer of the map won't draw? Any help is massively appreciated. Thanks,

                      Stephen


                      I'm not sure what you mean by "colour coded default areas of the map".  Can you include some screen shots of what this looks like, and perhaps also what you're expecting it to look like?  It sounds like, given the display area of the Map control, some parts draw and some parts remain white (or your control's background color).  Is that true?
                      • Re: Windows 7
                        asmguru62
                        Hi,

                        I have a different issue on Win7 than the one mentioned in this topic.
                        So, here are some details:

                        A 32bit EXE file calls CWnd::CreateControl() and specifies "MapObjects2.Map.1" as a ProgID.
                        Or, maybe it specifies the CLSID, mapping to that control name... not sure. At the end -- it calls
                        CoGetClassObject() and then factory creates an object itself. Or should create it...

                        Works OK on WinXP (32bit).

                        Does not work on Win7 (64bit). In debugger I see ERROR_NO_TOKEN returned from one of the
                        calls into OLE32. Also, later there is a code ERROR_SXS_KEY_NOT_FOUND is returned. I was
                        stepping through code in debugger on Win7, so it is basically ASM code, but I can see GetLastError() value.

                        When I was running MO24rt.EXE on Win7 to install the run-time -- I got a strange message with
                        a button "Click Here if program installed successfully." I clicked it. Something about the possibility
                        of an old application having issues on Win7?..

                        In REGEDIT I see that all MapObject2 entries are in place and refer to MO20.OCX - so it is correct (I hope)?
                        However, there is no "ThreadingModel" specified for any of these classes. So, by default the model is
                        "Main STA", which is STA allocated within the process who calls for a creation of control instance.

                        The thread that calls CWnd::CreateControl() also -- BEFORE it -- calls CoInitialize(NULL);
                        I feel there is a security problem, however, how to fix it?

                        EXE runs "As Admin".
                        Should I ran the MO24rt.EXE also as an admin?
                        Or maybe add "ThreadingModel=Apartment" to every class in Registry?
                        Did anyone see this before?

                        Thanks for any help.

                        Cheers!
                        Alex.