So I have 3 split containers, with 2 panels each.
SplitContainer1 is the main container that is docked in the Form ( Parent ).
SplitContainer1.Panel1 contains SplitContainer2 which is docked.
SplitContainer1.Panel2 contains SpliContainer3 which is docked.
So far so good.
SplitContainer1 has a SplitterWidth of 3.
SplitContainer2 and SplitContainer3 has a SplitterWidth of 6.
In the Designer, you can see the SplitterWidth difference between them, but when I build the solution, the SplitterWidth of SplitContainer2 and SplitContainer3 gets reset back to 4 no matter what I do. I have changed the code in "InitializeComponent" of the form with no effect.
The only way I got this working is in the Load Event of the form, re-specify the SplitterWidths which I find completely dumb. Why won't the SplitterWidths stay at the value I specified in the Designer?
If anyone can shed some light on this, what would be awesome!!
Thanks for your time,
Peter
Just so that this isn't left unanswered for eternity -
This is an old bug that has been in Visual Basic for many versions now, and is never addressed (nor is it likely to ever be addressed).
As Hans Passant mentions, the issue is due to the ISupportInitialize implementation for the SplitContainer.
Since it's a bug, there is not definitive way of resolving the issue that makes any logical sense.
One way, which I've tested in a mock up program, is as #xfx says - Add and manipulate the controls programmatically, rather than using the toolbox.
An alternative is to reload the SplitterWidths programatically, whether that's on Form_Load, which is most likely, or anywhere else in the code that it may be required.
Related
I have written an app that makes extensive use of custom right-click menus on an Access form. The code works great and the user loves it, but lately I am having trouble making it work properly.
In earlier versions of Access it worked well, but newer version seem much more limited in how many items can be put in such menus. The documentation is silent on the matter, and nobody in any newsgroup has had any useful ideas, but I regularly get random error about stack space, out of memory, and general lockups when populating the menus. Doing a C&R used to help, but now even that is not enough, and some menus I can no longer populate at all.
I tried building an app that just built menus until it crashed, to get some idea of what the limits may be, and I am well below what that indicated, but the experimental app had nothing else, while the real app has a great deal else.
Is there any information on how much stuff can be put into these menus, and what the menus share space with? There may be something I can do another way to make more room for the menus. I tried moving all code out of the form, leaving only event stubs that called routines in standard code modules, but that did not help.
And how are they stored/activated? The app is MUCH slower to load when it has these menus, even though no code is running on start-up.
********** Edited to add this:
I use VBA to create a menu, like this:
Application.CommandBars.Add "RCStat", msoBarPopup, False, False
then add it to a control. like this:
Application.CommandBars.cboStat.ShortcutMenuBar = "RCStat"
I add controls (only popups and buttons) like this:
Application.CommandBars.Controls.Add(type:=msoControlPopup)
Application.CommandBars.Controls.Add(type:=msoControlButton, Parameter:="StatKod = 77")
It runs perfectly and the menu items work exactly as expected, except that it bombs after adding some number of controls. It doesn't seem to matter where I add them, just the total number of added controls hits some undefined threshold, and the app crashes.
I got the original code from Getz, Litwin and Gilbert, 2000 edition. Back then, it worked great. But as the versions advance and the app accumulates data, it is becoming less and less functional. However, there are only around 10,000 records, and the app itself is less than 100MB - nowhere close to any of Access's upper size limits.
Pete,
I've done quite a bit of work with shortcut menus, and created the Access Shortcut Tool about 5 years ago, but have never attempted a menu with so many controls although some have 3 or 4 levels.
I am not aware of any restrictions on the number of elements in the commandbars collection, but I find that shortcut menus with too many options, like lists and combo boxes with too many items, are difficult for users to navigate. I generally break these up into segments and use buttons in the form header to display the appropriate menu. Sorry I'm unable to provide anything more helpful.
Dale
We have a commercial product, Total Access Components, that includes as one of its 30 components a right click popup menu that can include icons and font styles.
Here's the info for the popup menu control: https://fmsinc.com/MicrosoftAccess/controls/components/popup-menu/
There's a free trial if you want to try it.
I am using VB.Net is Visual Studio v16.6.3
I started getting this problem a few days ago on an application I developed two years ago and have been improving on and off. This error appeared out of now where. My DataGridView is OK at design time. when I launch the application, all forms that contain a DataGridView, it will appear all blacked out - as per image below.
If I minimize the form and return to it, the datagridview is fine, as per image below:
I get the same problem, in design mode or on a compiled executable. I have not tried this on some elses computer yet to see if it is graphics-card related or application related. Anyone has any idea how to resolve it? I did notice that if I move the datagrid binding and display from the "new" contructor to the "shown" event, it sometimes fixes the problem - but not always. Very weird and random.
I finally found it. I have to call the Refresh for my datagridview... I don't know why. Did not have to do that before but it works.
If someone can explain the reason behind this behavior, please tell me.
Tab Order in Visual Studio does not work for me for some reason.
I am making a VB.NET plugin for a cad program called Rhinocreos 5.
I have everything set perfect, and I don't know what the cause of it is.
I am using .Show() instead of .ShowDialog(), because I need that thread open and I don't feel like doing any thread management (not paid enough lol)
Does anyone have any pointers for this? Has anyone else ran into a tab problem with Rhino5 and .NET?
EDIT**
Seems I have to use a MODELESS Form for a rhino plugin.... So I wont have any tab keys or arrow keys unless I do a hook. But since I need to make the plugin future proof (in case I am no longer working here), I won't be doing that either. But thanks for the answers, comments, and awesome downvotes.
Very difficult to guess what's going on from the information you have provided, but I'd check the following things in the following order:
The disobedient form is open and has focus.
The form has controls in it.
At least some of the controls are enabled, focusable have their TabStop set to true.
There is no low-level keyboard handling in action (PreviewKeyDown, hooks etc).
Finally I'd call ShowDialog() instead of Show(), passing main form as parameter (to make disobedient form a child of main form) and see if that makes a difference.
It was a modeless form inside of Rhino3D as a plugin.
Rhino3D uses all plugins in the main thread. So tab is not an option.
The workaround was to tag all controls with a tag work (I used "tabMe")
Then I store all the controls in a List myTabbyControls.
Each time I press tab, I would cycle through the list.
But thanks for the down votes. It's the running joke of SO.
I'm using Dymola but I expect OpenModelica might very well be the same (or at least similar).
For a given component model sometimes it makes more sense to have lots of parameters shown on one "tab" of the parameter GUI. This can lead to an excessively long GUI which, for many reasons including for psychological reasons in relation to how humans process information, is not a appropriate solution.
To solve this I would like to add a vertical scroll bar on the parameter GUI. I believe I saw it once though I cannot recall exactly where.
For illustrative purposes look to the right side of your web browser window. That gray bar that goes up and down is the scrollbar :). I know, obvious but you never know.
I assume I need to put some command in an annotation somewhere though where and what command I am not sure. For example, I found some reference to a verticalScrollBarPolicy but alas, I can not find any documentation on this.
Anyone know how to do this?
EDIT #1:
Dymola (and Adrian indicated OpenModelica as well) will automatically create the scroll bar when the GUI gets larger than the screen. Unfortunately (at least in Dymola) there is little margin so if you GUI is a fraction smaller than the window the "OK" button will be covered by the ribbon on the bottom of the screen and the GUI will be needed to made slightly larger to make the scroll bar appear automatically. This is a reason why a manual option for a scrollbar would come in handy.
I think additional "tabs" might help?
As far as I know in OpenModelica we have a scroll bar for that dialog windows if the window would expand out of the screen.
As of this posting my understanding based on feedback on this forum, my own experience, and from additional discussions with others there is no current manual control of the GUI (i.e., size, scrollbars, etc.).
Your best bet if you come across issues (e.g., you have a super small 2nd monitor) is to use lots of tabs and keep descriptions very short (which is probably appropriate for most applications anyways).
This is a Dymola and OpenModelica issue not a modelica issue as it is not contained in the modelica specification (as I understand it).
If this changes and I find out about it I'll remove or update this post.
Sorry in advance for the vague conditions in which the problem below occurs. It is very intermittent, and I have not pinned down a consistent set of steps that reproduce it yet. (Which is why I'm asking for some general or common things that might cause it)
The application I'm working on consists of MonoDevelop.Components.Docking dock frames. There is a tabbed group of panels in one if the frames, and one of them has a GtkTreeView in it. Every now and then, the nodes of the Treeview will not expand when clicking on the + button. This does not go away until restarting the application.
However, since I have not been able to consistently reproduce it, I'm kind of at a loss of what to look for/mess with to fix it. So does anyone have any ideas on what might generally cause the nodes to not expand when clicked? Or any better steps I should try in order to reproduce it?
I have found this occurs when a disabled node is in the TreeView. In my case it was a project in the solution pad of MonoDevelop that was set to not build in the current configuration. When I removed the project, all other nodes in the TreeView started working again immediately.
You can use the arrow right/left keys to expand/collapse nodes.
It may be related to a Gtk bug:
https://bugzilla.gnome.org/show_bug.cgi?id=675835
which was fixed recently:
http://git.gnome.org/browse/gtk+/commit/gtk?h=gtk-2-24&id=b32a9eb691920f21ad3b9127c833aaba15727c4b