I am developping an Excel addin in C#.
This addin contains panels with some buttons to open hovering Forms.
I have been notified that this feature doesn't work anymore with one computer in my company. It uses Excel Office 2016 to the latest version.
Here is what happens:
The grey box is what should be a Windows Form, but for some reasons it doesn't load up. The user clicks a button to open it, and it just stays grey with no controls, no events, no response of any kind.
Now, here is the code that should open the Form :
private void _Form_CellDoubleClick(object sender, DataGridViewCellEventArgs e)
{
// ActiveForm() returns basically a UserForm with some methods to fit my specific needs
ActiveForm().ShowMyForm(_columnButton); // --> ClickEvent
}
public void ShowMyForm(object parent = null)
{
ActiveForm().StartPosition = FormStartPosition.CenterScreen;
if (parent != null)
ComputeLocation(parent);
IntPtr handle = new IntPtr(Excel.Hwnd);
ActiveForm().Show(new WindowWrapper(handle)); // --> Shows a grey box
}
public class WindowWrapper : IWin32Window
{
private IntPtr _hwnd;
public WindowWrapper(IntPtr handle)
{
_hwnd = handle;
}
public IntPtr Handle
{
get { return _hwnd; }
}
}
I'm giving this code just in case, but I'm not really sure it is faulty.
The exact same code works perfectly fine on any other machine, and the problem occurs with any version of my addin.
I've checked it with several (stable) versions, and even with a beta version, the issue still occurs.
However, it appeared after the addin was reinstalled to a previous version on the computer. It isn't supposed to mess with anything external, but I believe it is important to point it out.
I'm using a msi installer generated with Wix 3.11 to install.
I have not modified the code, but here is what I have tried. I hope this isn't ridiculous, I'm kind of unexperienced with this:
- Uninstalling and reinstalling the addin,
- Repairing Office 2016 and then Uninstall/Reinstall when it wouldn't change anything,
- Updated the .NET version from 4.6 to 4.7.2 (the addin requires 4.6)
- Updated the graphic card drivers on the computer
In addition, I've tried to check logs to see if any kind of error was generated:
- My addin shows no error in the logs
- I've set up the Visual Studio project and started the addin on debug mode, with breakpoints and all --> no error of any kind
- I've checked the Windows Logs Events and found nothing related. I might have missed something since I'm not experienced to read them.
I have finally found a link that "did something" :
How to revert to an earlier version of office 2016
I reverted the Office version to 16.0.9330.2118, and the Forms started working as expected for around 30 minutes. Then I was notified that the issue had come back, even though nothing had been updated on the computer. It just "went wrong again". I updated Office to the latest version and it started working again until next morning.
As you can see, no error is generated, but swapping the Office version to a different one "does something". It looks like some kind of conflict with some Office libraries, but I have no idea what to do or how to deal with that.
Even though I've noticed a few topics that looked like my issue, they were all related to code and Forms management. I really believe this has nothing to do with code, even though I can't prove it for certain.
Can anybody help me with this? Even some thoughts on how to deal with this issue would be appreciated, since I'm really not comfortable with it.
EDIT:
So I kind of figured out what happened, but not entirely.
I did what #HansPassant told me and ran the VS debugger on my colleague's computer, step by step, and got it running again and again.
It appeared what was causing the issue was the ComputeLocation method (see the original content).
Basically ComputeLocation worked like this (I simplified it a bit):
private void ComputeLocation(object parent)
{
Control parentControl = (Control) parent;
Point location = parentControl .PointToScreen(new Point(0,0));
//Process location's coordinates here
location = parentControl.PointToClient(location);
ActiveForm().StartPosition = FormStartPosition.Manual;
ActiveForm().Location = location;
}
I finally noticed that the issue would happen when using PointToClient. The Form would change its location but its content wouldn't.
I got the expected behavior upon removing the call to PointToClient.
I'd like to point out that this code is actually faulty (as opposed to what I was saying in the original part), because ActiveForm() is a topMost Form and has no parent. Using PointToClient in this context is a mistake because its location is always expressed in screen coordinates, although this is not what caused my issue here : in this context, PointToClient always returns a location that is almost the same as the screens coordinates.
I ended up removing permanently the call to PointToClient, clearing the issue. The content of the form followed its container again.
I still have no clue why PointToClient causes this behavior.
A few days later, another colleague got the exact same issue whereas nothing had been updated on his computer. The addin went from running normally on an excel workbook to displaying grey boxes on the next one.
I don't know if I should mark this question as solved since I was able to remove the issue, but do not fully understand what causes it.
I believe I have found what caused the issue here.
The problem "spread" to 2 more computers in my company and I was able to fix them with the correction I made, even though I didn't know the real cause.
One more issue appeared over time: ToolStrips controls weren't displayed anymore in the add-in forms.
Ultimately, one of my coworkers had to update his Windows version and it totally wiped out all of the issues.
I checked, all 3 computers were running on Windows 10 Version 1709.
I found a link about this version issues, but I'm not entirely sure this is exactly what caused the faulty behaviors:
https://support.microsoft.com/en-us/help/4340917/windows-10-update-kb4340917
The other machines were quickly updated to the Windows 10 April 2018 upgrade, and everything is running fine again on every versions of the add-in.
Related
I have a problem when using latest version of Microsoft Visual Studio Enterprise 2022 (version 17.2.2) running on Windows 10 Enterprise (Version 10.0.19044 Build 19044, if that matters). The problem is that the Visual Studio "hangs" at random moments, but not completely. By that I mean that it looks like everything's fine with it, but I just can't click it. By fine I mean that for example when I'm debugging an application and VS hangs, the app is running completely normal, everything's showing up in VS and for example breakpoints are hit normally. When it happens, I can also close VS from the task bar normally and it unloads everything peacefully. Like I said - everything's completely normal, but it's like VS is behind a glass. Also, like I said - it's completely random and sometimes it hangs when VS is in the background, but it also happens when I'm writing and it freezes mid word. The cursor is flashing, but I can't type anything and VS doesn't respond to keyboard and mouse clicks.
It's not that big of a problem, but it is quite annoying nevertheless, especially when it happens few times a day, about once every 2 hours.
The weird thing about it is that it only happens when I'm doing stuff in a specific project - a VSTO plugin for Outlook written in C# (hence the tags). I can have multiple windows (and solutions) opened at one, but when it happens, only one of them freezes - and it's the window with the VSTO plugin for Outlook. I don't know if that's the problem with the solution/project or if it's something with Visual Studio.
Like I said - it's not that big of a deal, as I can just close it from the taskbar, but it is quite frustrating and I'd like to fix it. Any help would be appreciated.
EDIT: More than a month has passed and I think this question needs to be updated. During that month I updated everything - Visual Studio to version 17.2.5, ReSharper (more on that later) to version 2022.1.2 (from version 2022.1.0) and Windows to version 21H2. And nothing helped. However I have some observations that I think I have to share.
First of all - answering matthew-watson's question - yes, there is a plugin involved and it's the aforementioned ReSharper. I feel quite stupid, because I completely forgot that I had it installed since I started using this PC - I just didn't use it. When I started using it nothing (in terms of this question) has changed - because it has always been there. However I'm not sure if ReSharper is here to blame - at least not completely. I tried disabling it few times during that month and it seemed liked it helped, because there were no "freezes" when it was disabled. Usually after few hours I turned it back on - I like ReSharper and I'd rather not stop using it. But I'm not sure it really helped - maybe it is just so happened that there were no "freezes" when it was disabled, that it was pure accident, as there were days when ReSharper was enabled and there were no occurrences of this bug. Moreover other people in my office are using the same configuration as me (same PC, same software - including the same version of Visual Studio, ReSharper and Windows) and they don't have this bug. I'm starting to wonder if my PC is cursed...
Secondly - it's not just Office VSTO plugins that cause those "freezes" (hence I crossed that section out). Since I asked this question I changed the project that I'm actively working on and observed that the bug also happens in other projects. It doesn't matter what project, it happens in all of them - simple console projects, Blazor projects etc. However I am quite sure that it happens more often in VSTO projects. Recently I came back to the VSTO project I had been working on previously and the bug happened at least 5 times on one day. In other projects it happens rarer. Though - as mentioned in the original post - it is completely random. There are days when it doesn't happen at all and days when it happens every 30 minutes or so. It's really frustrating. But - as mentioned - it happens more often in Office VSTO plugins for some reason.
Also - I did try repairing Visual Studio by choosing "Repair" option from Visual Studio Installer - it didn't help.
At this point I kinda gave up on solving it - I tried every solution that came to my mind, checked everything and I couldn't find anything - neither a reason for this bug to happen, nor a solution. If one could at least point to where to search for the correct logs and how to debug this problem, I would be thankful.
EDIT 2: Another 2 weeks have passed and I'm sad to have to tell you that this question will have to remain unsolved. I have left the company that I worked for in which I had this problem and so I won't be able to test any solution. Especially that it was only I that got this "freezing" problem, so I won't be able to ask my ex-work colleagues to confirm that any solution posted here managed to solve the mystery and fix the problem.
If anyone gets the same problem, I hope you will be able to fix it and share some details with us. I'm really curious as to what might have been causing it.
I am developing an Excel add in Visual Studio 2015. Target version is 2010. I tested it on a freshly provisioned machine with Excel 2016. Everything is fine and behaves as on my dev machine, except that two date time picker controls are missing from the dialog/form - the only form anyway. Machines are running Windows 7 and the .net runtime is 4.6.1. Was. I upgraded to 4.6.2 because on the Excel 2016 test machine someone saw that .Net version installed so I obliged, though I was pretty sure it won't solve anything.
At the same time a colleague with a Windows 7 machine too and Excel 2016 doesn't exhibit the problem. So it's not an Excel incompatibility between versions.
Any ideas what could cause this? Ideas of how to at least troubleshoot?
As promised I wrote a bit of code that lists all the controls added to the Controls collection of the form. I deployed that and to my surprise this time the datetime picker controls were displayed. The testing environment is not under my control and it is provided to me as virtual machines. Other than the troubleshooting code I did not add anything so I am stumped.
Anyway, one thing to remember out of all this is that if you write a handler for the ControlAdded event of the form it will be added to the designer form file after the statements that add the controls to the form. The alternative was to write a for loop and enumerate them in the Load event handler for the form. You can move the handler registration too before the Add() calls but it will be overwritten next time the designer generates new code.
If the above wouldn't offer enough information to solve the problem (very probable) then my next step would have been to use the Fuslogvw.exe to look for any assembly binding load failures, though I didn't have many hopes with that too.
If the issue occurs again, and especially if I find a solution, I will come back and update this.
I'm trying to embed Excel 2013 in a WPF app. The problem is that when I call SetWindowLongPtr in the following code, Excel 2013 crashes immediately. I digged it and found that if I comment out WS.CHILD style, it works fine, but the Excel sheet becomes readonly, which is not what I want. The same code works fine with Excel 2010.
Excel.Application _excelApp;
IntPtr _wrappedApplicationHandle;
Int64 lngStyle;
Int64 lExStyle;
private void Button_Click_1(object sender, RoutedEventArgs e)
{
_excelApp = new Excel.Application()
{
Visible = true,
DisplayFormulaBar = true,
};
_wrappedApplicationHandle = new IntPtr( _excelApp.Hwnd);
lngStyle = GetWindowLongPtr(_wrappedApplicationHandle, (int)GWL.STYLE).ToInt64();
lngStyle &= ~(int)WS.CAPTION;
lngStyle &= ~(int)WS.SIZEBOX;
lngStyle |= (int)WS.MAXIMIZE;
lngStyle |= (int)WS.CHILD; //<< crashes with this line
lngStyle |= (int)WS.CLIPSIBLINGS;
lngStyle |= (int)WS.CLIPCHILDREN;
SetWindowLongPtr(new HandleRef(_excelApp, _wrappedApplicationHandle),
(int)GWL.STYLE,
new IntPtr(lngStyle));
...
}
EDIT
Some more information as I'm digging through. I tried wrapping the above code in a try/catch block to see what happens. It never reaches the catch block. Excel 2013 crashes with the infamous "Application has stopped working. Send report to MS" error. I have already turned on all Win32 / COM / C++ Exceptions in Visual Studio (through Debug menu > Exceptions dialog), but that doesn't help either. There is a Debug button in the error dialog. If I click that and open a debugger, the error msg I see is " 0xC0000005: Access violation reading location 0x0000000000000000."
I also found that commenting out the WS.CHILD line in the above code doesn't strictly make the worksheet readonly. It just blocks common keyboard/mouse input from reaching the worksheet. But some keys like the context-menu key of the keyboard still reaches there and the context menu is shown (right-clicking through the mouse doesn't work though). Similarly, I can interact with the Office Ribbon through the mouse. It appears as if only the worksheet area (the grid with the white background) is not receiving keyboard/mouse input.
EDIT 2
I just recalled that (apparently) in contrast to what Hans Passant has explained in his post below, VS2010 hosts an Excel instance in itself when you create a Excel VSTO Workbook project. Though I don't have VS2013 (Full) with me and can't confirm, I suspect VS2013 would do the same with Excel 2013 VSTO Workbook projects. Considering that VS2010 and above are all WPF applications themselves, how does that fit in the picture?
EDIT 3
That private interfaces theory suggested by #acelent (see comment below) appears to be correct. I spied into VS2010-hosted Excel instance and found that there was a new window with classname = EXCELI which is not there when we normally open Excel (normal hierarchy of windows is XLMAIN (application) > XLDESK (workspace area) > EXCEL7 (workbook)). Also that workbook is no longer available as an ActiveX object, which used to be the cases back when Office Web Components library was available (last shipped with Office 2003). So all in all, we seem to be on a dead end and I'm going to suggest #Hans's answer to my client unless someone comes up with an actual working method in the next few hours.
You'll need to give up on this, you cannot make it work reliably.
WS_CHILD cannot work by design, Windows has the rock-hard requirement that the parent window and its child belong to the same process. They pass messages between each other, the child will crash when it tries to dereference a pointer that belongs to the parent's process.
Windows does have some appcompat support for SetParent(), required because this was commonly done in Windows 3.x programs. The notion of processes with separate address spaces was entirely absent in that Windows version so it wasn't a problem back then. The odds that this still actually works properly after 20 years is proportional to how much the process behaves like a Windows 3.x app. It works okayish for a console window or a simple app like Notepad. Office 2013 apps are considerably beyond simple and 3.x. Having trouble with input is certainly a hallmark for this. You could tinker with AttachThreadInput() to try to solve it but you'll likely just run head-on into the next problem, including its nasty habit of causing deadlock when you debug.
Embedding Office apps used to be a strongly supported feature in Office, Microsoft intentionally designed them to be embeddable. The underlying technology was called OLE Linking and Embedding. This technology is however strongly deprecated. Support for it was intentionally left out of the .NET Framework. Office 2003 was the last version that still supported it well. Trouble started at 2007 and it was completely scrapped for 2010. It will not come back.
The way ahead here is the exact opposite one. Don't embed the Office app, let the Office app embed you. Writing add-ins for Office programs is strongly supported.
I took over a Keyboard hook project and have been sprucing it up a bit. It used to be just 4 forms that had all the logic and maths in those 4 files. So MANY hours later I just about got the program back together after decoupling everything. The latest bit is by using the Model-View-Presenter design concept on the main window. All my tests work great on my machine, and naturally the program performs like it should on the target computers.
The target computers are simple x86 Intel Atom processors with 2gb of ram. They have buttons on them that correlate to F13-F18 on a keyboard (that is where my keyboard hook program comes into play). My development PC is a semi-stout 6-core AMD x64 machine with 8gb of ram. One thing I wanted to do was test out a way of setting those Function buttons to a particular task. All my unit tests pass for this portion. When I click on a new task type it works as desired.
"Cool", I say, "Lets see it in action" so i hit run in Visual Studio. I my program that F9-F12 are the keys to hook. Now the assignment window only opens up when you press one of the hooked keys when the main window is open. If that main window is not open then the task is performed. So I open my main window and hit F9 and the Assignment window shows but i can't click on anything for about 4 seconds. Then it "catches" up and does what ever I clicked on. I thought maybe it was my debugger so i went to the bin folder and ran the application directly and same deal.
I thought maybe it was a permissions thing so I ran as admin and same problem. I wondered how bad it would be on the target computers. I copied my bin folder to a flash drive, copied the content into Program Files and ran it. It worked great (well to a certain degree) But the problem was not present. I can select any task I want immediatly after the dialog is visible.
One strange thing is though that my keyboard hook stops working after 11 times of trying to reassign it...but that is a separate question. So i thought I remember someone saying, use a profiler. Well my visual studio had one so I turned it on but i can't make heads or tails of the data returned. I'd post code, but I don't know what to post. I even went as far as using System.Console.Write("."); around the area I thought was the problem but that wasn't the problem
protected override void theHook_RegisteredKeyPressed(System.Windows.Forms.Keys key)
{
if (TakeOver)
{
if (!Busy)
{
busy = true;
LibraryTrace.Start("NewKeyAssignment", key);
using (var window = new AssignmentTypePanel())
{
presenter = new TaskPresenter(window, theList[key].Task);
window.Presenter = presenter;
//execution will not continue past here until window is closed
window.ShowDialog();
}
theList[key] = new TaskKey(key, presenter.Task);
LibraryTrace.End("NewKeyAssignment", theList[key].Task.ToString());
busy = false;
}
}
else
{
base.theHook_RegisteredKeyPressed(key);
}
}
So i'm stuck. I can't figure out what to type, what to ask. Any tips on how i can find the root of this problem?
I had a similar problem with an application i developed using winforms- the 'server-side' operation was lightning-quick, but still the form showing the results took ~5 seconds to show.
Upon investigation, it turns out that winforms has some known performance issues.
There are some suggestions for optimization (like here or here and a few others i've found at the time but can't seem to locate right now).
Actually, none of them helped in my case.
I ended up realizing that the real bottleneck was creating and displaying a new form; what I ended up doing was a bit of a hack-
I placed ALL of my controls on the main form, with some of them hidden, and simulated a change of forms by hiding some controls and displaying others.
It's quite ugly, and won't scale up, but worked very well in my case.
I'm building a Windows Forms application in C#, and testing on Windows 7 64bit revealed a silent crash.
The exact line that it fails on is this.ResumeLayout(false); near the end of the InitializeComponent() function. It's a part of the Visual Studio generated code from the Forms Designer.
There is no exception, no popup to show the program has crashed, nothing. It simply ceases to run once it hits that line. This only occurs in 64bit. Removing that line, the program runs, but cannot be maximized, and there are several other oddities related to window properties.
I've tried everything from changing build settings to using CorFlags.exe, nothing has helped. What could be the issue?
If it makes a difference, I'm using OpenTK and the GL Controls.
Had an identical problem, only in my case the software ran on some 64-bit systems and not others. For example, my laptop is a vaio pcg series bought just this year. 64-bit Windows 7 Home Edition, 1600 x 900 resolution. Program runs just fine here. My colleague has a vaio svz series, 64-bit Windows Professional with 1920 x 1080 resolution, and for some reason his kept getting the silent crash on the ResumeLayout(false) call.
Again, commenting out the this->SuspendLayout() call near the top of the INitializeComponents() sub, and the this->ResumeLayout(false) call near the bottom fixed the problem, and the program seems to run fine on both systems now.
I had the same exact problem with ResumeLayout(). It ran fine on several machines, but I had one user who had it throwing "Exception has been thrown by the target of an invocation." Not very helpful. Unfortunately they also hide some of the details from Exception.StackTrace. I consulted with our resident expert and he felt it was a resizing issue. I discovered exactly where the problem was after going to DEBUG-->Exceptions and selecting everything. I then got a break right inside a function I was using to reposition some checkboxes. For some reason this was throwing an out of range exception on this user's box...
Rectangle rect = dataGridView.GetCellDisplayRectangle(col, row, true);
The point being that selecting the break on exceptions options as I described helped me pinpoint the actual problem. The workaround that others mentioned is fine, but in this case I was able to find the root cause.
Do you use some external component?
Some OCX which is not compatible with 64bit? I had your same trouble using GdPicture.
If so, try to compile for 32bit and problem could be solved.
A simple solution to this whole ordeal was to simply remove both the offending ResumeLayout() call and its corresponding SuspendLayout() call at the beginning of the InitializeComponent() function. It seems to have had no ill effect on the layout of the window despite having a heavy number of controls on the window. Again, this was only for 64 bit machines, the issue never popped up on Windows XP or 7 32 bit.
I'm still baffled as to why the ResumeLayout() call was causing a silent crash in the first place, and still feel slightly uneasy about the "solution", but it seems to have worked.