I am quite new to visual studio. Developed previously with vba.
Encountering a problem writing a language translation class.
The language dependent values are stored in a localdb table every row having formname , controlname and controlproperty as wel as a column per language.
The Language class Handles the translations at runtime. For forms I use a Sub FormUpdate(frm as Form) called from the form's load event as FormUpdate(Me) it checks the form's language kept in a custom parameter against the current language and updates the .text property of the controls on the form that are exposing some language specific text (Buttons, Labels, Tabcontrol etc..).
However I could not solve how to access and update the form's Tooltip component from the language class. (in vba it was easy as every control was exposing it's Controltiptext property)
In the form's class you would use MyTooltip.Settooltip(CtrlName,Text) but I could not figure out how to do that from another class (the tooltip component is not part of the form's controls - and I could not figure out nor find info how to do it) ??
Could someone advise pls?
I was so focused on finding a similar way to the one I used before that I did not see the easy way to resolve it - not yet enough accustomed to the new environment.
Sure, I am interested in an answer to my question but instead of making it too complicated using external components I'll do it the easy way by overloading the FormUpdate sub adding a sub with an extra parameter as Tooltip.
Let's start with a confession: I came from a VB6 background, and I'm accustomed to coding within the events of objects on a form, and as such my code for events ends up in somewhat random order in the code window. With this habit, it's never been very important to remember the names of controls (although I name them well)... I just double click on a button in the design view, which brings me straight to the code for that control's primary event. If I forget the name of a control, I click it and view properties. It's not a habit I've moved away from.
Well, now this is catching up to me. Using VS Express 2013, I have a form that contains a HUGE number of containers-within-containers, labels, buttons, and other doohickeys. I ported my code from VS.NET Express 2008 where this wasn't a problem. But now the act of selecting any control in the design view takes around 10 seconds before I can view its properties. If I drag to resize a control, and another 10 seconds passes before I can select another control. It makes designing this form nearly impractical.
In this particular project, I'm using use a tab control (which is never visible to the user) to design many "screens" which each contain panels full of controls. The panels for each "screen" are moved out of the tabs and docked into the main form as requested by the user changing screens. (I'm using the term "screen" to mean a window full of controls, usually maximized.)
Within the same project, a simple modal password-change form isn't slow to edit controls visually, even if the complex form is still visible in the IDE.
My question is in three parts:
First, what the heck is it spending all that time doing?
Second, is there a setting I can tweak to improve the speed?
Third, should I give up on trying to speed it up as-is, and move each "screen" into its own form for design purposes to avoid this slowness? (It's a lot of work to do that now... see next paragraph.)
Thus far I have avoided separating "screens" onto separate forms because I don't want a new window to come up when users change screens, and because code for the controls in one screen may affect the properties of controls on other screens... In such cases I prefer not to write out
form.doohickey.text = "blah"
..but rather keep it as ...
doohickey.text = "blah"
I'm using VB but I don't think this question is VB-specific.)
First off, I feel your pain. I have a management section of the application that I'm writing and I'm using a TabControl as well. I have 10 tabs so far and I've only added controls to about 4-5 tabs. I just added up the controls I have and there are about 360 controls so far on this one form and the designer file is ~3300 lines long. Currently anytime I change a property value of one of the controls or go to save the Designer, it takes about 3-4 seconds each time. I have a fairly decent machine; i5-3320M, 8GB RAM, intel 330 SSD, and it still takes a bit for it to do things within the tabControl. It also takes FOREVER to open and load the designer on that form...
What I've found is that it is easier to open a new instance of Visual Studio, create a test application, add a TabControl with the same properties, and design a new tab page from there. When I'm done I do a copy-paste into my actual project. This works great except for the few custom controls I've written in my main application project, I just have to sit and wait while adding them.
I'm now answering my own question. This is the approach I've ended up using, and it helps a lot...
My overall goal was to have an interface that didn't present a lot of windows, but still presented many different "screens".
I used to place all the different controls of different "screens" on separate panels, which were each contained in separate tabs of an invisible TabControl. I would then move those panels to my main form as needed by changing their Parent property of each panel as needed. The only problem with this is that the Winforms designer got ridiculously slow as the number of controls on a form increased into the hundreds.
Now, I am now designing each "screen" as a separate form, each of which contains a panel whose Dock property = Fill. Such a panel contains everything else on the form. The form itself never becomes visible.
As needed for to view various screens, I execute:
ScreenForm.Panel1.Parent = Mainform
...or, depending on how I lay it out...
ScreenForm.Panel1.Parent = Mainform.PanelXYZ
...I also either unload or hide any panels which already exist in the panel's new container.
I was GLADLY SURPRISED to find that the code for the various events of the controls contained in the panels would still run, because such code exists in the first form's file, not the displayed form's file. Luckily, it seems I was wrong. Event code follows the control itself. I can copy/paste not only controls, but also their corresponding event code to new forms for easier development and a faster Winforms designer.
All of this is similar to a MDI interface with maximized windows, but no title bar or [X] is displayed.
Essentially I'm doing everything as I did before, except using separate forms with panels instead of separate tabs with panels. The WinForms designer is much quicker because there aren't so many controls on any form.
I think I accidently found a workaround for saving a lot of time when changing the name of a control on a overpopulated container/project. Before you change the name, toggle False/True the "Generate Member" property of the control you want to rename(I believe you can also locate this under the "Name" property). This adds a few more clicks to the procedure but saves a lot of time. My not-yet-finished project has over 4000 controls and multiple forms and some of them are very "heavy" (10 - 20 seconds to normally change the name of a control). This, of course, don't help in anyway with the loading time of the project (about 35 seconds for me) but I can live with it. Let me know if this works for you too.
I just upgraded from VS 2005 to VS 2012. This is a new issue that I do not understand. I am using the default "Form1" class the VS automatically creates. I added a button to open a file open dialog and when I click the button I get this error:
Current thread must be set to single thread apartment (STA) mode before OLE calls can be >made. Ensure that your Main function has STAThreadAttribute marked on it. This exception >is only raised if a debugger is attached to the process.
I have added " to Public Class Form1:
<STAThread()> Public Class Form1
But I get this...
Attribute 'STAThreadAttribute' cannot be applied to 'Form1' because the attribute is not >valid on this declaration type.
I have searched but get some info telling me that I need to set the entry point (Form1 I believe) to be Single Thread Attribute but the above code does not work.
How?
The <STAThread()> attribute cannot be added to classes like your form. It only works when it is applied to the Main function, which is the entry point of your application.
But VB.NET hides this function from you because it is rare that one needs to mess with Main in a WinForms application. It is just needed to get the plumbing set up for your app, which the compiler can manage for you. This is controlled by the "Application Framework" checkbox in the project options. If this is checked, the compiler automatically generates the Main function and the required plumbing. You can disable this option, but it makes life quite a bit harder for the average WinForms developer because you'll have to write and maintain your own Main function.
The real question here is why this is a problem at all. The compiler-generated Main function for a WinForms application is always going to have the STAThread attribute applied to it. That is just how the WinForms framework is designed to run. If that is not happening, then there is something badly wrong with your project. I would recommend scrapping it and starting over letting Visual Studio create a new WinForms project from one of the built-in templates. Everything should Just Workâ˘.
The other option, of course, is that you're trying to display the OpenFileDialog on a separate thread (other than your main UI thread). But from your description in the question (adding a button to the form to display the dialog), it doesn't sound like this is the case. Regardless, the solution is not to do that. For example, if you're using a BackgroundWorker to do work on a non-UI thread in order to keep the UI responsive, that's great, but you'll want to do all of the UI stuff like showing an OpenFileDialog on the main UI thread before invoking the BackgroundWorker. There is a way to set a particular thread's apartment state using the SetApartmentState function, but I really don't recommend showing an OpenFileDialog on a background thread.
I am currently programming in Visual Studio 2010 within VB.NET and am using DevExpress v10.2.
I just started programming with the WinForms XtraGrid FindPanel and so far it works wonders. However I was wondering if there is any way to know when the user closes the FindPanel. Right now if gridview.OptionsFind.AllowFindPanel is True and gridview.OptionsFind.AlwaysVisible is False then the user is able to click on the x and close the FindPanel. Is there anyway to catch this closing? I don't want to stop it just do a couple of things once it is hidden or closed.
Thanks
Apparently DevExpress Gridcontrol doesn't have a separate event for whether the FindPanel is hidden or shown. Instead I used the GridView's Layout event and inside checked if the FindPanel was visible or not with: gridView.IsFindPanelVisible
Hey, I'm building a code editor app in VB.NET (Framework 4.0) and it opens all ".por" files into individual forms consisting of a MenuBar and TextBox (multi-line).
Currently I have 20 forms (all duplicates of the first on I designed) and if there are say 4 ".por" files in a directory, the first four will open up while the others hide.
I think it would be far more efficient by coding a new form For each item in form1's ListView...but I want the next so many to be a copy of the first form I designed since I spent a good bit on it.
Thanks in advance!
I decided to use tabs instead.
It wasn't difficult, the problem was I didn't know how to use a form I couldn't see.
By sticking to tabs and making a huge IF statement, simply making a new tab for each new file, and I'm getting used to using controls which haven't actually been created with the designer.
Just passing through a wall here...