locked
ActiveX Modal Dialogs do not work in IE7 RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Our product is suffering some pretty severe problems because of IE7. We've starting getting calls that dialog windows become hidden. We've heard this is a threading issue. We found out that the problem is actually much worse.

    Modal dialogs don't seem to function correctly in IE7. You can recreate the problem using VB6 by doing this:

    1. Create an ActiveX UserControl project.

    2. Add a form to the project (form1) 

    2. Put a button on the user control (usercontrol1).

    3. Add this code to usercontrol1.

    Private Sub Command1_Click()
       
       Dim objForm As Form1
       
       Set objForm = New Form1
       Call objForm.Show(vbModal)
      
    End Sub

    4. Build the project as an OCX somewhere on your hard drive.

    5. Find your control's CLSID in regedit. It is the default value in 

    HKEY_CLASSES_ROOT\Project1.UserControl1\Clsid

    6. Create an HTML file with this code. Replace the CLSID GUID with the one identified in step 5.

    <HTML>
    <BODY>
    <OBJECT classid="CLSID:{95ED95BA-9ECB-4D15-91AE-A7809742B65A}"></OBJECT>
    </BODY>
    </HTML>

    7. You can open the HTML file normally or host it in IIS if you want to get around some default security bubbles.

    8. Press the button! Press it again and again!

    NOTE: I'm branching off another thread I've read in this forum. There may be more information on the original thread.

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=686657&SiteID=1&PageID=1

     

    Tuesday, November 21, 2006 11:55 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Just got an email today that the hotfix is complete. They're working on the KB article now. Here's the link I was given to the KB article. As I'm posting this article now, is not yet completed.

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;930828

    Please remember: If this link does not work, then they are not done with the KB article.

    Tuesday, January 30, 2007 11:41 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Here are some key points towards working around the problem.

    1. With the above example, the problem does not present itself if you change the threading model from "Apartment Threaded" to "Single Threaded". This works in both IE6 and IE7 so far. I'll bet this fixes a lot of people's problems.

    2. Behavior is slightly different between specifying

    Call objForm.Show(vbModal)

    and

    Call objForm.Show(vbModal, Me)

    In IE6, the top Show method is more susceptible to modal dialogs being stuck behind the Internet Explorer window.  It only occurs when the dialog is in a different project than the control, however. We're not sure about IE7 entirely yet.

    Unfortunately, if we set all items in our product to single threaded, it crashes IE7. So, we're still in a rut. Meanwhile, I fight back the urge to complain about IE7 in all caps.

    Wednesday, November 22, 2006 12:09 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Johnny, I think you mean that the bottom method (using Me as a second parameter) is the problematic one.  To elaborate on your crashing comment, as we found in testing, the following steps will crash IE7:

     * Create a new UserControl in VB6, and add a Form to the project
     * Add a button to the UserControl
     * In the button's Click event, show the form [Dim f As Form1 / Set f = New Form1 / Call f.Show(vbModal)]
     * Load the UserControl in IE7 using Johnny's method above
     * Click the button to spawn the form
     * Get focus back to IE7 (right clicking on the taskbar icon will do it)
     * Press ALT and navigate to the View menu, and select Refresh
     * The modal window should disappear as the control is reloaded.  If it doesn't, dismiss the modal window
     * Navigate the browser to another page

    IE7 should crash, trapped by the Error Reporting crash handler.  I am of the opinion that this is an IE7 issue, rather than a VB6 one.  Unfortunately I don't know another language well enough to try.  The behavior doesn't happen in IE6.

    Wednesday, November 22, 2006 6:25 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Great work Johnny! (both for starting this new, dedicated thread and for finding out that this might be a threading-issue).

    We shall certainly try changing our active x-controls to single threaded and see what happens. I'll report back as soon as we find the time to try this. We have convinced the organization (our customer) that uses our application to block users from installing IE7, so we have bought us some time to fix this issue :)

    In the meanwhile it would be nice with some official Microsoft-reply to this issue. Are they looking into it? Do they see this as an issue at all?

    /Rickard
    Monday, November 27, 2006 3:24 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I've got a little more bad news:

    We thought using objForm.Show (vbModal) would screw up the form's position on the screen if it needed to show up "CenterOwner". We figured we didn't have to worry about it because we're using "CenterScreen". However, IE7 does not seem to support CenterScreen correctly either! IE7 will use CenterOwner, even if you supply the owner when showing the form. You can get it to show CenterScreen if you have Project1 reference Project2 and let Project2 show the form while supplying the owner. This has problems of its own too, though that I'll explain in the next post.

    Monday, November 27, 2006 5:10 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Here's the next problem other people might face. We have over 20 VB projects in our product, which means OCX's utilizing other OCX's and DLL's, etc. There are some pretty bad problems surrounding this as well.

    I noticed in other threads people are experiencing a problem with modal dialogs going behind the IE window in both IE6 and IE7. This can occur if you have more than one project.

    1. Create Project1 (OCX), invisible at run time, and have a public method show a Form using .Show (vbModal, Me). Compile this project.

    2. Create Project2 (OCX), reference Project1, and have a button call the public method described in step 1. Compile this project.

    3. Start an IE window hosting the Project2 OCX, and press the button (which should show your form).

    4. There are many ways to hide the modal dialog. The easiest I've found is to click twice on the IE window in the taskbar. This will hide the window behind IE. The only way to get back to your modal window is to Alt+Tab.

    The solution we've found is to specify .Show(vbModal) without the Me designation. This works in both IE6 and IE7.

    Monday, November 27, 2006 5:18 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Yet another problem. This is IE7 specific.

    1. Create an OCX project that shows a Form using a Button. Compile it.

    2. Open an IE7 window.

    3. Use File-> New Window (an action I perform many times in a given day)

    4. Navigate to the HTML file that hosts your project's OCX file.

    5. Click the button.

    6. Close the form.

    7. Your original IE7 window will now get focus and move to the front of the screen.

    This one me stumped. I could not solve this problem. However, it is only IE7 specific. These bugs are really starting to get to me; I feel like a beta tester when all I'm trying to do is make our product work.

    I've contacted Microsoft IE7 developer support about the main modal dialog issue and recieved a case number. I'll keep this thread updated with the progress.

    Monday, November 27, 2006 5:25 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    One of the VB developers from Microsoft tells me they know about this issue and are planning at hotfix for it. The fix is tentatively planned for about two weeks from now, so it sounds like we'll have something to include in our installation mid-december.

    They gave me a private build of the hotfix (that they asked me not to distribute), and I'm happy to announce that it fixes the modal dialog problem! This private build of the fix still has issues with windows being stuck behind the IE window, but they're intending to resolve that before they release the official hotfix.

    I was not expecting this, but the hotfix I recieved involves only a change to the visual basic runtimes (MSVBVM60.DLL). Because of this, the hotfix installation will require that all visual basic applications are not running.

    Friday, December 1, 2006 11:03 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    One of our users has found a workaround:

    If you minimize the parent window, then you have access to the modal window and you can operate it.

    This works at least for our OCX.

    So, we could at least advise the users to search for the lost modal windows and to use them. It is not nice, but at least we could use our OCXs till Microsoft comes with a hotfix.

    Monday, December 11, 2006 4:40 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Has MS given any further update to you on when the hotfix will be available?
    Thursday, December 14, 2006 2:12 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    has the hotfix been released?
    Thursday, December 28, 2006 12:45 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I was told the same as Johnny and received the private hotfix (again I was told not to release to anyone) and so can confirm that the fix works.

    I have since been told that the hotfix has been delayed as it encountered a different problem. As soon as they've solved that they said the hotfix release would be made public.

    Unfortunately that was over 3 weeks ago. I'm still receiving updates, but thet are all saying "not yet sorry"

    I'll post here as soon as I hear anything positive

     

    Richard

    Tuesday, January 2, 2007 7:33 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Could you share the KB number, or any other info that you may have.  There are a few other people asking about this, and I'd like to see if we can expidite this.
    Thursday, January 4, 2007 9:21 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Three weeks ago, the person working on the IE7 modal dialog issue gave me an email, and it seemed that things were close to getting done:

    Once we have verified that this new dll works correctly then we will move onto a final QA stage, final build, and then I will be able to get the final hotfix to you and ready to distribute to your customers.

    The fix worked for our problem. However, we noticed that you can still give the parent window focus and access the "View" menu using the "Alt" key, then get to "Refresh" a couple times and crash the browser. I told them I didn't really care about this, but he seemed interested in fixing it. A couple days ago I emailed him back asking how things were going, and got a reply:

    I am working on this with our VB6 developers as I am typing this email.  The issue is difficult to track down since it spans parts of the OS, IE, and VB, but we are actively working on it.  And now that everyone is back from vacation I am hoping to have some updates very soon.  I will let you know as soon as I have more information, but please feel free to call or email me if you need anything.

    They probably just stopped working on it for the winter holidays. I doubt I actually slowed the progress of the hotfix, but I'd sure find it funny if I did. I probably won't tell them about the other problems I've found, just to be safe!

    Thursday, January 4, 2007 11:34 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    stefanluchian,

    You might try the single threaded option we found. If you don't have many timers or instances of your activex controls, it will probably work for you until the hotfix comes out.

    Also, don't forget to use    .Show (vbModal, )  instead of .Show(vbModal, Me). The microsoft contact specifically confirmed that this code change would be required for the fix to fully work.

    Thursday, January 4, 2007 11:39 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

     

    I am already using single_threaded.

    Unfortunately, for the OCX I am using Borland Delphi and the function I call is MessageDlg, which makes a call to ShowModal, without parameters, so I cannot give something like "Me". I see in Borland's code of ShowModal that it uses the Self (I think is the "Me" correspondent from VB) to make it the focused form, but I'm not sure what further is the code making in background.

    So, I only hope that the hotfix will fix also my kind of the problem.

    Thanks anyway for your answer.

    Wednesday, January 10, 2007 2:12 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Does this private hotfix resolve the problem only in OCX ActiveX or does it also work for DLL ActiveX ?

    Here's my problem :
    The behaviour of the showModalDialog function has changed in IE7. It pause all the client-side scripts running in every frame of my website, instead of pausing only the scripts running in the frame which called the showModalDialog function, like in IE6. I used this function to block user interactions while a frame is loading, for example.

    I already looked a lot for a solution to this problem & i thought about making a DLL ActiveX in VB6 : i wrote a small function who displays a form as a modal dialog (with this code : "[MyModalWindow].Show 1" or "Call [MyModalWindow].Show(vbModal)").
    Under IE6, it works fine : the user can spam click wherever in IE, nothing will happen, till the modal window is closed.
    Under IE7, the modal dialog can disapear under the IE7 window, and the user can interact with the window. :x

    So i'd like to know if the hotfix will fix that problem ?
    (i think i'll ask an expert from Microsoft France if he can get this private hotfix, so i'll be able to test myself)

    Thanks.

    PS: sorry about my poor english

    Friday, January 19, 2007 4:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Yep, that's the issue that this hotfix will resolve.
    Friday, January 19, 2007 7:27 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Sorry to ask that again, since someone already asked about it, but is it possible to have the KB number of this fix ? So it would be really easier to ask for it to the MS expert i work with.
    Thanks.

    Monday, January 22, 2007 9:10 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    In delphi, initialize your ActiveFor as follows

    initialization
        TActiveFormFactory.Create(
        ComServer,
        TActiveFormControl,
        TTC40Admin,
        Class_TC40Admin,
        1,
        '',
        OLEMISC_SIMPLEFRAME or OLEMISC_ACTSLIKELABEL);

    which is setting the threading model by default to tmSigle.

    Also, make sure your Forms and Frames are parented to the ActiveForm NOT the browser window. Do not use Create(nil) and always set the Owner. MessageDlg is a correct function, is parented to the calling window which may dock correctly inside the browser window but which may be parented to the... desktop instead of the ActiveForm. That sends the modal dialog back to the desktop as the last on the Z-order and gives the focus to the browser window which is at the TOP of the Z-order (this screwes up the entire logic of the modal dialog and the ModalResult is lost).

    Microsoft says you should use tmApartment but that just does not work so until they fix it. that is the solution.

    Monday, January 22, 2007 4:54 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    If you want to create ActiveX'es in delphi, initialize your ActiveFor as follows

    initialization
        TActiveFormFactory.Create(
        ComServer,
        TActiveFormControl,
        TTC40Admin,
        Class_TC40Admin,
        1,
        '',
        OLEMISC_SIMPLEFRAME or OLEMISC_ACTSLIKELABEL);

    which is setting the threading model by default to tmSigle.

    Also, make sure your Forms and Frames are parented to the ActiveForm NOT the browser window. Do not use Create(nil) and always set the Owner. MessageDlg is a correct function, is parented to the calling window which may dock correctly inside the browser window but which may be parented to the... desktop instead of the ActiveForm. That sends the modal dialog back to the desktop as the last on the Z-order and gives the focus to the browser window which is at the TOP of the Z-order (this screwes up the entire logic of the modal dialog and the ModalResult is lost).

    Microsoft says you should use tmApartment but that just does not work so until they fix it. that is the solution.

    Monday, January 22, 2007 4:58 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Draga Bogdan,

    Do you suggest that Delphi is not parenting the components to the ActiveForm, even if I created them at design time using the default drag-and-drop delphi IDE-Tools behaviour?

    I have some events (which are calling that MessageDlg function) associated with some tables (which are using one TADOConnection) that belong all of them to the ActiveForm and were created using IDE. Do you think that at design time the TADOxxx components are not correctly parrented to the TActiveForm? How should I create them? Do you suggest to create them by code and not by delphi-ide-designer?

    The initialization of the ActiveForm was already called as you suggested, trotzdem throw the calls to MessageDlg inside that events the Dialog behind the browser. I have only one form, no other frames or fomrs; it's all simple and uses only the ActiveForm as (I hope) parent.

    I use also speciffically tmSingle in the call by I don't think that this makes any damage.

    Friday, January 26, 2007 10:25 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Just got an email today that the hotfix is complete. They're working on the KB article now. Here's the link I was given to the KB article. As I'm posting this article now, is not yet completed.

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;930828

    Please remember: If this link does not work, then they are not done with the KB article.

    Tuesday, January 30, 2007 11:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Why did you change the original name of the thread?

    I think this is not a good ideea, because people will not then easily find the answer to their problem.

    Is it possible that you change it back to the original name: ActiveX Modal Dialogs do not work in IE7 ?

     

    Wednesday, January 31, 2007 12:32 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Sorry, I think that the problem is from the forum, or from my browser, that the name shown above has something to do with the name of the last reply...
    Wednesday, January 31, 2007 12:34 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    How is this hotfix implemented? What is it a hotfix for VB or for IE7? Any more information would be greatly appreciated.
    Tuesday, February 6, 2007 8:22 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    The only file in the hotfix is: msvbvm60.dll

    I'm not at my office right now and I don't remember the version number, but it is greater than that of the currently released VB6 SP6 runtime DLL.

    Thursday, February 8, 2007 2:21 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Unfortunately, the hotfix is still unvariable

    Any ideas?

    Thursday, February 8, 2007 6:32 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I spent quite some time with MS IE7 support team tuesday and came away unresolved. I would prefer it being a vb6 dll that I can deliver as part of a cab file. Do you have any recommendations on how I can fast track getting the updated VB6 dll?
    Thursday, February 8, 2007 4:11 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I suspected as much, but I'm not allowed to give you the DLL I have. In fact, I don't know if I'm allowed to even give it to my customers yet, so I haven't packaged it.  Anyway, here's what he told me today.

    Johnny,
     
    Thanks for asking me before sending it out to the forums.  The EULA you received was specifically for you and cannot be transferred.  And the DLL you received was specifically based on the terms of the EULA and the information you provided (ie. # of machines, redist mechanism, etc).  So no, you cannot upload the DLL to the forums.
     
    You can certainly point anybody to Microsoft support (800-936-5800 or http://support.microsoft.com/default.aspx?scid=fh;EN-US;OfferProPhone) and they can obtain the hotfix and a EULA from us.
     
    I am sending the article today to tech review so hopefully it should be online in the next couple days.
    Thursday, February 8, 2007 11:25 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    So does it mean that MS is not so serious abt this bug. This has been reported in October 2006 and its more than 4 months now. They have not yet released the fix. This is not good for a global service provider. Lot of customers are waiting for this. Any idea, why they are not serious on this?
    Tuesday, February 13, 2007 10:57 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

     kubaiju wrote:
    So does it mean that MS is not so serious abt this bug. This has been reported in October 2006 and its more than 4 months now. They have not yet released the fix. This is not good for a global service provider. Lot of customers are waiting for this. Any idea, why they are not serious on this?

     

    Yes, it's a very serious bug. My customers report this bug many times, but my have no ideas, MS must pay an attention on this.

    Does somebody know MS managers?

    Sunday, February 18, 2007 3:46 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    The KB is now available but we cannot download the hotfix. We have to contact MS support and pay the hotfix !

    And I don't know if it will correct my Delphi ActiveX !

     

    any idea ?

    someone can upload the hotfix ?

    Thursday, February 22, 2007 9:04 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Why does Microsoft not understand that this is not an exclusive VB problem, but a problem with all other software development platforms? I only hope that the fix will be a general windows patch and not a VB patch only.
    Thursday, February 22, 2007 12:54 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
     Johnny Kauffman wrote:

    stefanluchian,

    You might try the single threaded option we found. If you don't have many timers or instances of your activex controls, it will probably work for you until the hotfix comes out.

    Also, don't forget to use    .Show (vbModal, )  instead of .Show(vbModal, Me). The microsoft contact specifically confirmed that this code change would be required for the fix to fully work.

     

    This thread is exactly what I've been looking for, thanks!!

    Can someone please confirm two things:

    1) The line above should read ".Show (vbModal) instead of .Show(vbModal, Me) "?   VB6 rejects the line with an empty parm as shown.

    2) That the new vb runtime DLL has not been distributed by an MS automatic update and/or is still not available for public download?  My customers are screaming!

     

    Friday, February 23, 2007 3:00 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    1) Are you sure? Should be optional. Doesn't happen to me. I'm unable to explain why it wouldn't work (so, in other words, I'm not helping anymore on that one!)

    2) Right, last I checked you have to contact MS support to get it. It sucks but it should be available in at least that regard. That microsoft contact I had said they were working on making a download availble. Pretty soon that guy and I will be inviting each other to BBQ's and weddings and such.

    Thursday, March 1, 2007 7:17 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    HI guys

    Just to confirm Johnny's comments.
    I've also been told that you have to speak to Microsoft direct to obtain the fix.

    Additionally, the fix does not work for Vista. Or rather you can't apply it yourself. Vista blocks any manual changes to DLLs, so microsoft need to package the DLL themselves. I was told that they are working on this update.

    Richard

    Monday, March 5, 2007 4:02 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Guys,

    I don't think Microsoft has a fix for this bug. The modal windows are going to pop under in several occasions even if you set your threading model to SINGLE (for example if you open your ActiveX in a new window <<CTRL+N in IE>> all modal windows are going to pop under as the're parented to the original window, to IE, and thus they're going to STAY UNDER which is the frustrating part : you see the window in the taskbar but clicking on it results in a small flicker and the window is lower on the Z-order again)

    I found that the combination that helped my ActiveX controls is :

    - Threading Model : SINGLa (works if the Active Form is on the parent IE window)

    - Create an application HANDLE for your ActiveX. This results in the modal windows belonging to that new handle and thus when the window pops under and you click on the taskbar button, IT COMNES BACK ON TOP (you may also implement a BringToFront function to do that automatically) and STAYS THERE.

    Have a great Day guys

    Bogdan Badulescu

    making a Bynapse connection

    Thursday, March 8, 2007 4:13 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Why does it say that the forum has been deleted when I try to post the solution to it ?
    Thursday, March 8, 2007 4:15 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    In internet Explorer 7, Modal windows created in an ActiveX developped in Delphi pop under the main browser window. It's a known bug for IE7 that claims that has a hotfix (only for VB users) that does not really work.

    The only partial solution to this, as I found so far, is to:

    - Create your ActiveX using the SINGLE threading model. This solves a lot of problems in IE7 including the fact that the Modal Window is parented to your ActiveForm and thus.

    (Microsoft recommends Apartment, using apartment just does NOT work with IE7 as it parents your Active Form from the IE window to the DESKTOP whick ensures two type of errors : Parking Window Errors (DAX) and Modal Windows popping under the browser window and being blocked there (you see the button on the taskbar but clicking it would just result in a flicker and the window is pushed back on the Z-Order)

    IF YOU OPEN THE ACTIVEX in a NEW BROWSER WINDOW (Ctrl+N in IE), the Single threading model won't do it's trick as your ActiveForm will be parented to the original IE Window and thus your Modal Dialog will pop under your current browser window. This lead me to the next solution:

    - Create an Application Handle before you create the Active Form. (Application.CreateHandle)

    This ensures that the ActiveX has its own window and the Modal Window is parented to that. Even if the dialog pops under, clicking the taskbar button will bring it back on top (you can even implement a BringToFront to make sure it comes on top on its own) and it will stay there.

     

    Bogdan Badulescu

    Thursday, March 8, 2007 5:26 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Bogdan Badulescu, you are saying that the hotfix doesn't work. My company has received this hotfix from Microsoft about three weeks ago. It works for VB-applications, the modal dialogs ARE modal and stays on top.
    Unfortunately, in our application, the hotfix introduces a new bug. The modal dialogs are TOO modal Smile   We have a few modal dialogs that communicate with the webserver throught VB-events, for retreiving data based on user input. This used to work, but it doesn't anymore. The dialog fires the event, but the result is blocked until the modal dialog is closed. So the modal dialog never receives the result.
    But we are able to change our code and not use events so this hotfix is better that nothing.

    By the way: Applying the hotfix on machines with IE6 doesn't ruin anything, everything works as before there.
    Wednesday, March 28, 2007 8:00 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    This is just rediculous. They are not yet released the hotfix. I think they dont know how to fix this issue. Actived Tooltip is also having problem. I think somebody complain this before. Did microsoft stop working on this? Any idea..
    Thursday, March 29, 2007 5:27 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    MS has released the hotfix file package, but it's only for Window Vista (MSU file).

     

    How can I use the file on Window XP ?

     

    Any ideas?

     

    Thanks!

    Wednesday, April 25, 2007 9:01 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello,

     

     

    It was not evident to find un install for WinXP , it seems to me that Microsoft not been published any hotfix for XP,  just for VISTA .msu.

     

    Anyhow, I'm trying using this new VB 6 runtime, with the recommendation below

    .Show vbModal instead of  .Show vbModal,me

     

    Everything is working fine inside IE7 but without making F11.

    So if I make F11, I have the initial problem (ActiveX Modal Dialogs do not work in IE7)

     

    It seems that the problem has not corrected very well !!!!

     

    Faris.

    Monday, August 6, 2007 12:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

     

    Great !

    I corrected this problem under Delphi for IE7, but it came back with IE 8 (beta) !

     

    Thanks to MS to help us on other developpment tools.

    Thursday, July 17, 2008 1:14 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Here is how I fixed it for IE8. Works in IE7 and below and even works in the executable.
    http://bynapse.blogspot.com/2009/04/activex-modal-dialogs-are-pushed-behind.html


    Comment on my blog if you get a better (or different solution), will you ?
    • Proposed as answer by Badulescu Friday, April 24, 2009 1:56 PM
    Monday, April 20, 2009 6:29 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    http://bynapse.blogspot.com/2009/04/activex-modal-dialogs-are-pushed-behind.html
    Friday, April 24, 2009 1:59 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I had same trouble whith delphi activex dax errors IE7
    i have fixed them modifing axctrls.pas as follow

    function ParkingWindow: HWND;
    var
      TempClass: TWndClass;
      parkingname:string; //  // fiX dax error class name depending wondow handle IE7
    begin
      Result := xParkingWindow;
      if Result <> 0 then Exit;
     

      FillChar(TempClass, sizeof(TempClass), 0); // fiX dax error class name depending wondow handle IE7
      Parkingname := 'DAXParkingWindow_'+Format('%p',[@ParkingWindowProc]); // // fiX dax error class name depending wondow handle IE7

      if not GetClassInfo(HInstance, PChar(ParkingName), TempClass) then
      begin
        TempClass.hInstance := HInstance;
        TempClass.lpfnWndProc := @ParkingWindowProc;
        TempClass.lpszClassName := Pchar(ParkingName); // fiX dax error class name depending wondow handle WIth IE7
        if Windows.RegisterClass(TempClass) = 0 then
          raise EOutOfResources.Create(SWindowClass);
      end;
      xParkingWindow := CreateWindowEx(WS_EX_TOOLWINDOW, TempClass.lpszClassName, nil,
        WS_POPUP, GetSystemMetrics(SM_CXSCREEN) div 2,
        GetSystemMetrics(SM_CYSCREEN) div 2, 0, 0, 0, 0, HInstance, nil);
      SetWindowPos(xParkingWindow, 0, 0, 0, 0, 0, SWP_NOACTIVATE or SWP_NOREDRAW
        or SWP_NOZORDER or SWP_SHOWWINDOW);
      Result := xParkingWindow;
    end;

    For IE8 i have change initialization of activex

    initialization
      TActiveFormFactory.Create(
        ComServer,
        TActiveFormControl,
        TSuiviTPX,
        Class_SuiviTPX,
        1,
        '',
        OLEMISC_SIMPLEFRAME or OLEMISC_ACTSLIKELABEL,
        tmSingle); // fix dax error with IE8

    Hope it will help.

     

    Monday, April 27, 2009 10:44 AM