I have wierd issue with ElementHost on CustomTaskPane in Excel 2010 32bit on Windows 7 x64, .NET 4.0
Control inside Host (or host itself) is not repainted after workbook window was moved around.
To illustrate this I have created sample:
_host = new ElementHost { Dock = DockStyle.Fill, BackColorTransparent = false, BackColor = Color.Blue };
_userControl = new UserControl();
_userControl.Controls.Add(_host);
_taskPane = CustomTaskPanes.Add(_userControl, "Pane");
_taskPane.Visible = true;
I've omitted child control for simplicity, as result is the same.
Here is how it looks as expected:
Now I moved workbook around a bit, and I get:
Obviously grey and black areas are not expected (same result with actual control hosted). _host refresh fixes the issue -- repaints itself and child, but problem is I didnt find any event in VSTO to detect when workbook was moved.
Questions:
Where do those black/grey areas come from?
Is it possible to avoid/fix it and how?
(as a workaround) Is it possible to detect workbook window movement so I can refresh _host and pray its the only scenario it happens? (bad idea)
Other tests shows that windows forms controls doesn't suffer from this behaviour.
Thanks in advance.
You should put a true XAML user control into the ElementHost.
In your WPF user control, make a grid with background color = blue.
Don't rely on element host itself
Also check updates, elementHost in VSTO gets lot of bugs.
Related
I am facing an issue where a WinForms form is being automatically re-sized every time the designer is opened.
This only appears to happen with a certain setup, however it can easily be replicated with the following steps...
Create a new project in visual studio
The default form size is 300 x 300, but whatever you set it to make a note
Set the FormBorderStyle property to FixedSingle
Set the ShowIcon property to false
Set the ControlBox property to false
Save the changes
Close the designer
Re-open the designer and you will notice the form has shrunk by 4 pixels (both width and height)
The problem I have with this is that when it happens it does not resize any of the controls (i.e. the ones set with anchors), so this means I end up with controls that overlap the form edge and everything needs to be manually readjusted every time I open the designer which is a pain.
So the question is: Why is this happening, and what can I do to stop it happening?
I am currently using Visual Studio 2012 Professional, and John Willemse has confirmed via comments that this issue is also present in Visual Studio 2010 Professional.
I see it, this should be a bug in any VS version. It is caused by the ShowIcon property, the designer doesn't handle it correctly when you set it to False. At issue is a bit of code in the Form class that looks like this:
FormBorderStyle borderStyle = FormBorderStyle;
if (!ShowIcon &&
(borderStyle == FormBorderStyle.Sizable ||
borderStyle == FormBorderStyle.Fixed3D ||
borderStyle == FormBorderStyle.FixedSingle))
{
cp.ExStyle |= NativeMethods.WS_EX_DLGMODALFRAME;
}
In other words, when ShowIcon is False then it uses a different border style from WS_BORDER, it uses the one of a modal dialog. Which has different borders on older Windows versions, they are fatter. Not exactly sure what inspired this code, probably has something to do with Windows 98.
Problem is, the Size property is a calculated value, the Winforms designer only stores the ClientSize property. So when ShowIcon is False then it should redo this calculation, it doesn't.
You can report the bug at connect.microsoft.com but the odds that Microsoft is going to fix it are exceedingly low so it would probably be a waste of your time. There is a very simple workaround for it, instead of setting ShowIcon to False in the Properties window, do it in the constructor instead. Like this:
public Form1() {
InitializeComponent();
this.ShowIcon = false;
}
I've been working on a project in Visual Studio 2010 creating a large Windows form using C#. What's getting me is that whenever I feel I need a change to the layout of the form and open it in designer view, it will resize to a slightly smaller set of dimensions. Every time it does this I have to restore the size and relocate some of the panels as they get out of position. Would anyone know why this keeps happening? I've had to keep the designer window closed when not working in it because it will resize when I launch the project in Visual Studio, as well, if the view was left open when I last closed the project.
I am looking for that answer too. Here is something that may be similar to your question? visual studio 2005 designer moves controls and resizes Form
I had this problem in my project too.
Form Properties;
AutoScaleMode = Font
ControlBox = False
FormBorderStyle = FixedSingle
MaximizeBox = False
MinimizeBox = False
ShowIcon = False
ShowInTaskbar = False
StartPosition = CenterParent
I set my form size to 485:210. I save and close the form. I re-opened the form and size of the form changed to 481:206. I had no idea why this was happening.
First I searched around and couldn't find the solution.
AutoScaleMode set to Font in my forms.
Windows resolution is 1360 x 768.
I tried AutoScaleMode properties set to None, but the form size changed again. I changed Dpi but the result was same. I tried to use Docking for all controls in the form, but the result was same. I tried all answers which I found in stackoverflow.
I dont have any problem with my other forms. Then I realize that my other forms has ControlBox.
Then I set ControlBox properties to True. The size of the form not changed this time.
I am running into a very strange problem that I wanted to see if anyone else has seen. I have a C++ application (compile with CLR support) that has a MFC dialog which hosts a WPF user control. Every once and a while, the WPF user control will not appear when the dialog opens. The control is there as I can press a button on that user control. Obviously, I cannot see it, but the button still responds to a click event if I click the area where the button is supposed to be.
The strange part in all this is how sporadic it happens. Sometimes it happens the first time the user goes into the dialog after starting the application. Other times, it will happen after successfully going into the dialog a few times. We have deinitely not found any pattern to when it will happen. It just happens once and a while. Also, we have seen this across all different operating systems - XP, Vista and Win7.
To correct the problem, simply closing the application and relaunching it norally cures it.
In terms of the code, the standard approach for WPF user controls on MFC dialogs is being used:
// Create the initial object
System::Windows::Interop::HwndSourceParameters^ sourceParams = gcnew System::Windows::Interop::HwndSourceParameters ("BatchSelectionContainer");
sourceParams->PositionX = x;
sourceParams->PositionY = y;
sourceParams->Height = height;
sourceParams->Width = width;
sourceParams->ParentWindow = System::IntPtr(parent);
sourceParams->WindowStyle = WS_VISIBLE | WS_CHILD;
BatchSelectionDialogGlobals::gHwndSource = gcnew System::Windows::Interop::HwndSource(*sourceParams);
BatchSelectionDialogGlobals::gHwndSource->AddHook(gcnew HwndSourceHook(ChildHwndSourceHook));
// Save a reference to the new frame
BatchSelectionDialogGlobals::BatchSelectionFrame = gcnew ProteinSimple::ParticleDetection::Console::BatchSelection();
// Establish an event handler for the buttons
BatchSelectionDialogGlobals::BatchSelectionFrame->EnableExecuteButton += gcnew ProteinSimple::ParticleDetection::Console::BatchSelection::GeneralHandler(&BatchSelectionDialog::EnableExecuteButton);
BatchSelectionDialogGlobals::BatchSelectionFrame->DisableExecuteButton += gcnew ProteinSimple::ParticleDetection::Console::BatchSelection::GeneralHandler(&BatchSelectionDialog::DisableExecuteButton);
// Finalize the visual parts and return the handle
BatchSelectionDialogGlobals::gHwndSource->RootVisual = BatchSelectionDialogGlobals::BatchSelectionFrame;
return (HWND) BatchSelectionDialogGlobals::gHwndSource->Handle.ToPointer();
This is certainly a strange one. I have some of my users that have never seen it, while others it happens many times a day.
It feels like a bug in MFC in how it displays the WPF control. However, I have searched on-line and have never heard anybody describe this problem. The code is not throwing any exceptions, so I am not sure what the problem could be.
I am stumped and would appreciate any insight into the problem.
WPF doesn't draw the stuff as windows-controls as MFC or WinForms do draw - you can check it using Spy++. That's why its not possible/easy to mix WPF and MFC.
My windows forms application hosts AvalonEdit (the composite WPF control in question) in one of its forms to cater to its text editing requirements. Here's the code I use:
WPFHost = gcnew ElementHost();
TextField = gcnew AvalonEdit::TextEditor();
WPFHost->Dock = DockStyle::Fill;
WPFHost->Child = TextField;
TextField->Options->AllowScrollBelowDocument = false;
TextField->Options->EnableEmailHyperlinks = false;
TextField->Options->EnableHyperlinks = true;
TextField->Options->RequireControlModifierForHyperlinkClick = true;
TextField->ShowLineNumbers = true;
ContainerControl->Controls->Add(WPFHost); // the container is a panel
The code compiles and executes fine, except for the scrollbars - http://dl.dropbox.com/u/2584752/avalonEditBug.png . Right clicking on what's left of the bar raises an ArgumentOutOfRange exception.
Strangely, I wasn't able to reproduce the issue when I tried hosting the control in a newly created sample project. 'mI using the latest build of the text editor and have all the requisite assemblies installed.
EDIT: Wrapping the editor in a usercontrol doesn't help either.
You say that the control works fine in a new/blank project but fails in the one you need makes me wonder about conflicts more than anything. In the project you're really wanting compared to the project it worked in what are the differences? .NET version? Referencing an assembly from a directory in one but out of the GAC in another?
It's hard to say that the control is messing up for you when you've got it working elsewhere, so the only thing I can suggest is just dive deep into the differences of the two projects.
Good luck.
This looks like a layout error to me. Maybe WPFHost measures the TextField unexpectedly.
I can suggest setting specific Width and Height on the TextField itself. If this fixes the problem you can adjust those as the size of the WPFHost control changes or try setting the MaxHeight/Width, sometimes they help and save some code for Width/Height updates.
try to create a WPF grid as a child of ElementHost, and place the editor inside that grid. On Other way, is to create an UserControl have the editor in that control and use the control inside your Winform app. Such approach helped me a couple of times.
I've implemented a workaround for the issue as mentioned in this thread [ Synchronizing a WPF ScrollViewer with a WinForms ScrollBar ].
We have an MFC ActiveX control created in Visual Studio 2008 with CLR support which creates a WPF grid and shows a WPF window within that grid.
This ActiveX is hosted within Internet Explorer and it shows up and works nicely except that the tab key, backspace, function keys etc. does not work since they are handeled by IE instead of the WPF window. Regular characters works nicely. This is a known feature and previously when we used to have MFC based dialogs within this ActiveX we used this: http://support.microsoft.com/kb/187988. By just using this code directly the
AfxGetApp()->PreTranslateMessage((LPMSG)lParam)
statement will return FALSE, so I'm not able to get the key stroke to be handled by the WPF window. I beleive I need to ask the WPF application this instead of the CWinApp, but I'm not sure how and if this can be done. Does anyone have enough understanding of what's going on here to get this to work?
Using XBAP instead of ActiveX is not an option as this is run in an intranet application which needs more access than the sandbox can give us.
I hope this is enough information.
With best regards
Svein Dybvik
We have hosted a WPF user control inside an MFC modeless dialog. In order to get some keyboard stuff working correctly, we had to modify the dialogs PreTranslateMessage() function.
Basically, what we did was to check to see if the message was for the WPF window. If it was, we immediately call TranslateMessage/DispatchMessage and then return TRUE from PreTranslateMessage.
Our WPF control fills the entire dialog, so you'd have to have your own conditional check where we have the IsChild test.
BOOL CHostDlg::PreTranslateMessage(MSG* pMsg)
{
// normal PreTranslateMessage() causes the edit fields not to work
if (::IsChild(GetSafeHwnd(), pMsg->hwnd))
{
TranslateMessage(pMsg);
DispatchMessage(pMsg);
return TRUE;
}
return baseclass::PreTranslateMessage(pMsg);
}
Some edit:
BOOL CHostDlg::PreTranslateMessage(MSG* pMsg)
{
// normal PreTranslateMessage() causes the edit fields not to work
if (::IsChild(GetSafeHwnd(), pMsg->hwnd))
{
TranslateMessage(pMsg);
DispatchMessage(pMsg);
pMsg->hwnd = GetSafeHwnd(); // redirect to parent
}
return baseclass::PreTranslateMessage(pMsg);
}