My Windows forms application creates the user menus at runtime given the user access privileges.
It works fine, but when the app is minimized, then all menus vanish. The space is used, but the names and icons are gone (obviously no sub-menu is shown, due to top level menu items are gone)
It is coded using the class ToolStripMenuItem and previously this code is set:
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Does someone have seen this behaviour?
Regards
Daniel.
Murphy's... Months stuck with this... and the solution was as simple as this:
When creating the MenuStrip objects I set the AutoSize property to false. I commented that line and it worked perfectly.
Thank you Reza Agahei for reading this and being concerned about this problem.
I can't understand fully why this happens... but what is working... musn't be even stared at.
I didn't post any code because the menus where generated through abstract model objects invoked through reflection, but I will follow your advice Reza, if I have another issue.
Thanx.
PS. I love this site, I always have found answers to my problems here, and now I'm happy to be part of it.
Related
Working on a fairly simple database application in visual studio 2017 and c# with a login screen to unlock all the other forms. Working just fine.
Tried adding another form for another feature and suddenly this caused the login screen to be 'locked out', as in it appears on startup like it should but nothing is selectable, everything is greyed out.
I have tried removing every single reference I can find to the newly created form but still my entire program is basically broken from just adding a form. I had added forms before this with no problems.
I'm not expecting anyone to wave a magic wand and fix it but if anyone has any pointers of what to check or look for? Happy to answer questions and go into more specifics if needed.
I am building a project with the WindowsFormsApplication libraries and everything was going well until I noticed that the class properties are not being set at runtime anymore. The first instance occurred when I set menustrip hotkeys: the set in the designer, the code for it is there, I made sure nothing else would be sneakily altering the value(s) at runtime by using methods instead of the 'property' format. Then, somehow I managed to fix this by calling a method created specifically for setting menustrip hotkeys right after the initialization method.
NOW, the docking properties will not set or, in other words: I set a control's dock style to dockstyle.fill and when I maximize the window, it's as if the dock style was never set, but the code that says-so, is still there! the dock-fill property was working successfully only a moment ago...
I've searched for problems similar to mine for a good day and only found one result, but the questioner wasn't provided good answers ~in my opinion. I don't have much time so any help would be much appreciated!
In the mean time, I'll port all the controls over to a new form. That seemed to do the trick for two other occurrences with past projects...
I have had bizarre results with Visual Studio sometimes losing it's mind. Exiting and restarting seems to fix it. What version are you using?
I've been working on a small program which gets a list of url's from the web server ( latest forum topics ) and warns the user whenever a new topic is created.
So the main form of my program have a list of buttons. Each button has the text of the forum topic and extra information below. Opens the browser with the topics url when user presses.
The problem is, creating buttons for every topic doesn't feel right. I'm sure there is a better way to create a user interface for this program. I tried listview but I need space for some extra information so one line and one text-size isn't good for it.
edit: I'm sorry, it's a windows form app.
Try ObjectListView. Here's what can be done with it:
(source: sourceforge.net)
For this sort of thing I would look at WPF and style my own controls.
You can loop through them and add the buttons and labels programmatically. Placing them vertically below eachother is simple math.
Probably not best practice, but it has always worked for me.
I have a WinForm that uses an ElementHost to display a WPF UserControl. Once every 50 times or so when the form loads the WPF content fails to paint. You can see through the WinForm chrome to whatever is beneath. Resizing the window gets the WPF content to show up.
Is this a known issue? Can anyone suggest a workaround?
We have fought these types of issues before. See this WPF forum post for more info on our particular flavor (I don't know if it is the same issue or not).
The only thing that we found to work was to change the size of the ElementHost.
_elementHost.Width++;
It's a complete hack, ugly, and I'm embarrassed to even post it. But nothing else ever worked for us. So, it is definitely a workaround. (Grin)
We tried Invalidate, Refresh and everything we could think of ... on the ElementHost. We also tried InvalidateMeasure, InvalidateArrange, and InvalidateVisual on the WPF hosted content. No luck.
If you find another way to fix your issue, I would love to hear about it.
Good luck, I know I have lost some hair on this one.
Update 1:
I have submitted another WPF forum post on this. Maybe we can get a response from Microsoft. Sure seems like a bug to me.
Update 2:
After I fixed the refresh issue with the above hack ... I still had another problem to solve that I thought worth mentioning here. That is: there was a definite delay until the screen refreshed. This made it seem like the user was navigating to another screen (it wasn't ... it was just the contents of the double buffering buffer). I ended up having to manually call System.Windows.Forms.Control.Refresh() on the Control that was hosting the ElementHost. In this way, even though the pause was still there ... at least the screen was blank ... and it didn't look like the user was navigating somewhere ...
the following worked for me.
On the Form_Activated event, I added the following
elementHost1.HostContainer.InvalidateVisual();
I know this post is old, but in the later version of .net (i.e 3.5), you can try to use software rendering mode. This seems to fix a lot of problems when you host a WPF control in the ElementHost.
Ref: Software rendering mode - WPF
Maybe call Invalidate on the ElementHost?
Have you tried to use reflection to see the code behind _elementHost.Width++?
For some strange reason, my toopltip in the VS 2008 C# winforms application shows up behind the form! It's very frustrating and I can't figure out what I should do. Anyone face this before? Ideas?
(PS - I'm doing a toolstip.show programmatically within the form)
There are a few things you might want to check:
Make sure the tooltip knows what its parent window is.
Make sure the window the tooltip belongs to is in the foreground (no, this isn't a requirement for displaying tooltips, it just helps debug.)
Try giving focus to the owner of the tooltip. If that fixes the problem, then there's probably an ownership problem with your tooltip.
Try bringing your page element to the front. (Right click on element, bring to front). Is this happening on all tool tips you have configured? And no, I have not seen this before
There is a similar (and known) problem with tooltips appearing behind the Windows task bar. The problem is sporadic and I have never seen a solution. If you're also seeing this behavior sporadically (and I suggest that you try this on different machines), then it may be related. Otherwise, if the problem is consistent across multiple machines, let's see your code, because you're probably doing something wrong.
I have a similar issue. I have a user control written as C++ WTL, being used in a C# .NET2 app. If the control is just on the form then the controls tooltips work fine, however if the user control is on a panel or in a group then the tooltip is behind. I've tried changing the WTL code to force the tip to the front, this works but causes issues with lost focus/selection in other controls.
This problem is almost always caused by the window being TopMost. Try using SetWindowPos to set your tooltip to HWND_TOPMOST. I haven't tried this though...
I've seen this issue happen in both Windows.Forms and Delphi (native windows) based applications, caused by the interaction of "stay on top" with the Windows API.
Essentially, marking a form as TopMost makes it stay on top of some windows, but not others - Window management has more than two distinct levels.
What I found is this: my applications would behave themselves when run normally, with tooltips showing on top. Problems would occur when switching to- and from- other applications - somehow the "TopMost" of the windoww would become "very-ultra-top-most" (non-technical term ;-) ) with the tooltips appearing behind the window.
Having described the problem, I'd like to offer you a solution - but I never did find a good one. Sigh.
Hope that the additional information will be enough for you to find the solution you need.
I have seen this happen on Windows XP, particularly on the taskbar.
Are you sure it's an issue with your application, rather than the OS?