Forum

Hello

I am programming an application that is working as an IE plugin as well as stand-alone.

Now when I set a push pin in my plugin the view next to the tool bar is supposed to be resized. This does not happen and I assume it is because the view was not created with AFX_IDW_PANE_FIRST as id. I am not doing this because this will cause an assertion in the OLE part of the plugin.

Is there a way to force a recalculation of the layout in my derived AutHideModeSet method that will affect my view?

Thanks in advance

Thomas

The g_bEmbeddedMode is added for good.

We guess you are talking about resizable control bars. Could you provide a screenshot and a step-by-step description about what we should do to reproduce the background problem? The child view window can be un-painted if it’s not in the correct location inside the frame window. This can be checked by using the SPY++ utility. If our guess is correct, then you simply forgot to re-compute the layout of your embedded frame window at startup.

http://download.ierax.ch/whitebackground.jpg

Here is the screenshot you wanted. Cirled in red you see the area that I mean and that I would like to be gray instead of white.

Thanks in advance

Thomas Maurer

Hello

I found the solution myself: I did not install the correct paint manager in the in-place scenario. This also caused my "problems" with the status bar. I think and hope that I have solved all Prof-UIS related problems for my in-place version of the software.

Many many thanks for your support.

Thomas Maurer

P.S. You introduced a g_bEmbeddedMode variable into one of your classes. Will you introduce that into the product or will that remain a "Thomas specific" feature?

Hello

Many thanks for your (as always) great support. My in-place application is getting better and better.

Sorry to ask two more questions:

1) When I integrate your code into my "real" project the CChildView is not painted the first time it is displayed. I can easily make an UpdateWindow but the question is where should I do that. Is there some location that is called only once and only when all bars are correctly positioned?

2) I asked that before and I might have overlooked the answer: When the toolbars on the left are collapsed/unpinned the bar on the left side has a white background (apart from the tabs). How can I set this to gray? Some WM_ERASEBKGND or some window style at the right place?

Thanks again

Thomas

Hello

Thanks a lot for your modified solution. This is much better!!!

There are a few problems remaining which I would be glad you could help with:

- When a pinned toolbar on the left side is unpinned the toolbar is not collapsed when the main view gets the focus. It just stays where it was. There has to be some other event to trigger the collapsing. Can something be done about that?

- When the toolbars on the left side are collapsed they will only fly out when you open one of the toolbar’s menus. They are not flying out when you just click on one of them. This might have someting to do with the point above.

- The menus on the toolbars are reduced to what has recently been selected so when you open them the first time you only see the "down arrows". How can I make the menu display its whole content always (not depending on what was recently selected)?

- When the toolbars on the left side are collapsed the background of the toolbar is white and not gray. How can I achieve that it becomes gray?

- This is a MFC question I guess and maybe it does not have anything to do with Prof-UIS. Maybe you can help anyways: When I create the status bar in the in-place scenario it has this gripper on the bottom right which allows resizing of the status bar. This comes from not having the SBT_NOBORDERS style (according to Spy++). In my non-in-place mainframe I create the statusbar in an identical way and it does get that style.

Many thanks in advance

Thomas

We found out that the auto-hide areas with grouped tabs not always can determine that the IE window is active. So to meet the requirements described in your first two questions requires Prof-UIS to be modified. We added a g_bEmbeddedMode public static property in the CExtDynAutoHideArea class:

static bool g_bEmbeddedMode;

We also set its initial value to false and modified the beginning of the CExtDynAutoHideArea::_CanActivate() method:

bool CExtDynAutoHideArea::g_bEmbeddedMode = false;

bool CExtDynAutoHideArea::_CanActivate()
{
      if( g_bEmbeddedMode ) // THIS LINE WAS ADDED
            return true;    // THIS LINE WAS ADDED

      if( ( ! CExtPopupMenuWnd::TestHoverEnabledFromActiveHWND( GetSafeHwnd() ) )
            && ( ! m_bInsertMode )
            )
            return false;
. . .

Then we set this property to true in the CVEViewApp::InitInstance() (in your project)

  if (this->RunEmbedded())
  {
        CExtDynAutoHideArea::g_bEmbeddedMode = true; // THIS LINE WAS ADDED
    AfxMessageBox(_T("Embedded"));

    COleHandler::RunEmbedded(&m_oleserver);
    return TRUE;
  }

These two modifications should solve the problem with the auto-hide feature for control bars embedded in IE.

We added the following two lines in the constructor of the application class to make all the menus initially expanded and always displaying all its menu items

      CExtPopupMenuWnd::g_bMenuExpanding = false;
      CExtPopupMenuWnd::g_bMenuHighlightRarely = false;

Your last question is really more MFC-related than Prof-UIS-related because the CExtStatusControlBar class from Prof-UIS is simply a re-painted version of the MFC’s CExtControlBar. The CExtStatusControlBar class does not compute any layout of the parts of the status bar: it simply paints the status bar items and the gripper through the paint manager’s calls. It looks like the status bar common control constantly reserves some space for the gripper. Anyway we solved this problem in scope of your project by adding the ID_STATUSBAR_LAST_EMPTY_INDICATOR status pane as the last status pane with empty text.

Here is the new version of your project.

Please download a modified version of your application. The most important improvements are marked with PROF-UIS TECH SUPPORT. Generally, the embedded child view was incorrectly repositioned in your code. Some window classes were incorrect what generated flickering while resizing the embedded frame. All the control bar handles were attached to command manager’s profile to let toolbars display their icons while floating. All the frame/view windows were made clipping siblings/children to remove flickering while resizing the embedded frame. Please check this project and let us know if we missed something.

The new registry files allow us to run your test project embedded in embedded mode. Please give us one more day so we can play with your project.

We can compile and run the application, but we cannot embed it into IE. We have tried both the registration ways but in any case IE opens a file in the popup frame of your application rather than in the OLE embedded in-place frame. Could you try to do the same on a clean computer? We tested this with IE 6 on Windows XP SP2?

Hello

A most strange thing happened (which I am afradi I must solve properly when the software goes into production).

First the same happened at my computer = the program started outside IE. For testing I then started Word and I inserted an object of my "VEView AFP Document" class. This worked fine. When you activate the object you see my view. I think this is a good test to see if everything is registered properly for basic in-place activation.

After checking the internet I came across the following:

In HKEY_LOCAL_MACHINE\SOFTWARE\Classes\VEView.AFPDocument add the following DWORD value: "BrowserFlags".

Now the problem is what value to set it to. I didn’t read the kb article properly and set the value to 8. This means open the program in a separate window which it did but not with the usual frame but just a simple frame around the view.

I then read a little more and set the value to 1: same effect.

Then I set the value to 0: It worked!!!

Then I removed the BrowserFlags value altogether and it still worked!!! (and ???).

So I guess something caused IE to change its general behaviour.

HINT: Could you please set the BrowserFlags value to 0 at the beginning and see if it works? If it does that would make my life easier because I just set this registry value upon installation when we go into prodcution. If this doesn’t work you can still set the value to 8 (and if necessary to 1) and then back to 0. Of course you must open the test document via IE after changing the value.

FURTHER PROBLEMS:

1) I noticed that the toolbars - once unpinned - don’t close right away. Is that also due to lacking idle processing?

2) Reopening them once they are unpinned and closed often only works by pressing the right mouse key on them. Same problem?

Thanks in advance

Thomas

My post above sounds as if I had done that on my development computer but I did these steps on a clean machine as you suggested.

When I did this yesterday I remember I must have done something similar on my development computer a 2 months ago. But since I removed "BrowserFlags" from the registry again I did not see any traces anymore.

T.M.

Hello

My post from Oct 30, 1:03AM contains two things:

- How to register my program
- A few additional problems I found when using it as a plugin

=== How to register my program ===

What I wrote in my former e-mail was true for Windows 2000.
For Windows XP this did not work. Please do the following for XP (maybe also for W2K, did not test yet)

- download http://download.ierax.ch/Prof-UISRegistry.zip
- adjust paths in reg files (only document.reg has changed)
- register files

Now it should work without any other operation necessary.


=== Additional problems ===

The additional problems in my post from 1:03AM are still valid and I would be glad if you could take a look.


=== Comments for registration (if you are interested, not really relevant anymore) ===

I spent a few hours searching for this problem on the internet and nobody had a real answer. Not even Microsoft. I googled articles and newsgroups. At a certain point I decided to check with regmon what registry keys and values IE is checking and I came across a value named "BrowseInPlace". When I added that to my document class everything was fine. You can not find one single entry on microsoft.com about that.
This solution works for IE6 and XP. Let’s hope it is the key to success for W2K and IE7 as well!

Hello I have prepared a stripped version of our Software which you can download at:

http://download.ierax.ch/VEViewProfUIS.zip

In the Zipfile there are instructions too how to register the IE plugin.

Now you can see all problems live in the IE plugin.

Hello

http://download.ierax.ch/afterbeginning.jpg

Above link shows the IE upon startup. The document mode is set to page width = the document should occupy the whole width. You see that you can not really distinguish where the document ends and where the bar ends. The status bar looks strange too.


http://download.ierax.ch/closingbar.jpg

Above link shows the bar closed and the document is displayed properly.


http://download.ierax.ch/afteropeningagain.jpg

Above link shows the bar with push pin set again. Now the document is correct.


I accomplished this by deriving RecalcLayout with the following method (4711 is the id of the view)

void CViewFrameInPlace::RecalcLayout(BOOL bNotify)
{
__super::RecalcLayout(bNotify);
this->RepositionBars(0,65535,4711);
}


Let me know if I can help more

Thomas

You have correctly implemented the RecalcLayout() virtual method but the real problem is that your IE extension is an MFC kind of project which does not control thread’s message loop like MFC EXE applications do. The frame window layout re-calculation can be delayed by control bars inside this frame and the real layout re-calculation will be performed when the frame window reaches the idle state. This is detected automatically by the message loop processing code implemented in the CWinThread/CWinApp classes. In the case of COM objects like IE extensions, you should track some timer inside the frame window and implement idle time processing in it. This timer should have a 100ms period and its handler code should be as follows:

      CWinThread * pWinThread = ::AfxGetThread();
      ASSERT_VALID( pWinThread );
      pWinThread->OnIdle(0);

Could you provide more details about project type which implements the IE embeddable UI?

Could you send us a screenshot demonstrating the incorrect view position when the button is clicked?

I have solved this problem myself in the meantime by deriving RecalcLayout. I do not have the code here at the moment but will gladly provide it if you want it.

And yet, not all is working properly: When the push pin is set from the beginning the underlying view will not be resized accordingly but only when you release the push pin the view is adjusted. When you set the push pin again it works fine. Do you know what I could do to trigger the view size calculation from the beginning?

I think I would be able to construct an equivalent test project but it would take some time I guess.

We are sorry for the delay with this reply. Would you send us a test project that implements a UI similar to that in your real project and embeds itself into the IE frame? That would allow us to help you more efficiently.