I have a vb.net project that loads "plugin" dlls at runtime to crunch some data in slightly different ways and return the results. To do that, all the plugins implement the same interface, so the GUI couldn't care less how the plugin arrives at its final dataset, just so long as all the plugins deliver it back to the GUI in the same way.
I'd like to set up per-plugin options in addition to the main program options. I have an options form that accepts an object of type System.Configuration.ApplicationSettingsBase and displays the contents in a PropertyGrid control, so it'll show any My.Settings object the same way. Question is, how do I pull the My.Settings object out from a plugin that's loaded at run-time?
Figured it out. I used the My.Settings for each class library to hold the individual settings, and in my plugin interface, specified that each plugin should implement its own RaiseOptions() method, which would create a new instance of an options form, push the My.Settings object to the form, and then display those settings on the form's PropertyGrid control. Since the plugin is doing the calling, it is set to use the correct My.Settings object (rather than the My.Settings object from the GUI).
It did require adding a few references so that a class library could display a form properly, but IntelliSense was pretty good at pointing out exactly what I needed.
Related
new to .net coming from vba decided to rewrite a management app using vb.net and SQL Server.
Started writing the base library for my application.
I created custom controls to use in my application that would expose a Zoom function, background color for the current active control a .modified property similar to the one available in textbox and some extra other properties (SQLTableName, SQLColumnName, ...) to enable iterating through a container (form) for modified controls and Update/Insert into a SQL table via a SQLProcessClass.
Concurrently I'd like to also implement a simple undo functionality.
My first idea was to add a PrevValue variable set in the OnEnter event if the Modified property is False, exposing an OldValue property and an Undo method in the custom controls.
However I found that the TextBoxBaseClass already exposes an Undo method and that there is an UndoEngineClass available.
Unfortunately the vs helpfile does not give examples of how to use / implement that class.
Could someone explain the usage of the UndoEngine class non-textbox controls and if it is advisable to use it or rather write my own (as I first intended to do - I also found some interesting articles about undo/redo classes) but why reinvent the wheel in case .net already provides a class for it.
thks
I am writing my first VBA Add-In under Microsoft Office Word 2007 with Windows 7 Pro/64. Part of this Add-In is a UserForm. Using the Visual Basic editor that runs from Word, I find there are two ways of viewing, and two ways of modifying a UserForm's properties:
View all properties from Object Browser (F2)
View some properties and edit them from Properties Window (F4)
Manually enter and edit any property from the Code window (F7)
Here is a screenshot of my Properties and Code windows:
A problem I find is that the Properties Window contains only a subset of the UserForm's properties (notice that CanPaste, CanRedo, and CanUndo don't appear in Properties), and changes made in the Properties Window are overridden by changes made in the Code window (e.g., at runtime, Me.Caption from the Code window above overrides the Caption field in Properties).
I suppose I should avoid using Properties at all then, and enter all settings via UserForm_Initialize as shown above. But (a) for some settings, Properties makes several settings at once. For example, selecting Verdana Bold from Properties equals Font = Verdana and Font.Bold = True in Code. And (b) it seems Properties sets the subset of properties it controls to defaults of its choosing, and if I change them I can't see what they started out as.
I therefore desire unified and comprehensive access to all my UserForm's properties at once, including the aforementioned default settings. Does anyone know how to reveal a UserForm's default settings as code, or to automatically open all its current settings in the Code window? Is there an umbrella mechanism I'm not aware of?
I'm not a veteran VBA programmer, but I can't believe my experience is unique. I've searched the 'net in vain for a solution. How do you with more experience manage this dilemma?
You use the Properties window to set appearance-related properties at design time. Those property values will then always apply unless you explicitly change them at run-time with VBA code.
Properties that don't relate to appearance, such as CanPaste and CanRedo relate to the state of the form at run-time, so it doesn't make sense to have them configurable at design-time.
You can change nearly all of the properties at run-time, whether it is in the Initialize event or elsewhere. You can even add controls at run-time, but your changes won't be persisted once the instance of the form terminates.
When an object is created in the .Designer.vb file from the Windows Form Designer, is a Dispose() call generated automatically for each object or must this be done manually?
Specifically, I have an object that uses unmanaged resources (by calling ShowDialog(), requiring a call to Dispose()) that is created in the Windows Form Designer. Do I still need to call Dispose() on that object?
Note: It is advised not to call Dispose() more than once on the same object.
While I dont know the answer, let me tell you how you can get the answer and learn a neat trick for designing components for winforms (might work for others but haven't tried).
Assuming you have a project that already references your component, create a new project and set the "Start External Program" to "C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" (change this based on your version of visual studio, this is from 2005)
Run this project, which will then run another instance of VS. You have now opened VS in debug mode. Now open your project you are using to build/test your component (from the second instance of VS), set a break-point and test it. You should be able to see it hit your break-point in the dispose code.
This is great for testing VS Add-ins and designer components.
This was one of those questions where the answer is "because that is the way it works", but then you realize you don't actually know how it is implemented. So I spent a few moments to dig up the details.
Anything that is a Control (button, textbox, whatever) that is added to the Controls collection is disposed for you automatically. This implementation is inherited all the way back from the Control class itself.
Anything that is a non-graphical Component (like a Timer for example) that is added to the auto-generated components object in the MyForm.Designer.vb file is also disposed for you. In this case, components object, while implementing the System.ComponentModel.IContainer interface, will be an instance of System.ComponentModel.Container that handles the actual Dispose.
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.
Trying to get it to behave like C#, where there is a Program class with a static Main method.
However, in the project properties, I cannot set Program.vb to be the startup object, only the forms (it is a forms application).
Am I missing something?
I am using the VS2010 and the latest VB.
Uncheck Enable Application Framework in Project Properties.
You need to switch off “Application Framework” on the main page of the project settings.
The application framework provides its own entry point which sets up a few things that are subsequently used (e.g. application events, single instance checks etc.) and then just displays the main form using System.Windows.Forms.Application.Run. That’s why you can only supply the main form, not a custom entry point method.