I'm refactoring an existing VB.net application that is ~6,000 lines in one file, and I've encountered a dilemma.
On the one hand, I can use visual studio's Data Sources and drag-and-drop functionality to get rid of all the hand-written code that sets up the DataAdapters, DataSets, DataTables, CurrencyManagers and the manually linking between them all.
On the other hand, I can separate the logical pieces of my UI into User Controls.
Now, if I only do the first one, I end up with tons of controls all in the same form, which causes me to have tons of controls in the same 'namespace' that I have to manage, and forces me to write all custom UI logic and event handling in the code behind for the single main form.
If I only do the second one, I get the distinct visual pieces of my UI in separate files, which gives me an appropriate place to write specific event handling and formatting code; but it doesn't let me use the visual studio designer to hook my dynamic components (e.g. DataGridViews) up to the BindingSources in the parent form. The nice thing about this is that I get to set the myriad properties (column width, read-only etc.) in the GUI, which seems like it would make the project much more maintainable.
What's the sensible course of action here? Or is there some possible way to employ both tactics (which is what I would ideally like to do)? I'm definitely looking for some guidance here - I'm a complete vb.net newbie.
Thanks!
Related
I have a large amount (about 50) of SubVIs including beyond some usage specific code a small number of GUI elements (mostly about 2: input and output).
My goal is to reuse those VIs without creating a huge mess in a new ('main') VI and collect all GUI elements on a GUI common pane a user shall finally interact with.
I tried to use the Open VI Function, 'VI Reference' and 'Run SubVi' like in the examples to create references for subpanels, but the subpanel ui is only shown when the program is run and the amount of additional blocks is mostly bigger than the code in the respective SubVI.
The SubVIs should be loaded only once to construct the main User Interface.
In addition: In this tutorial they create a subVI and recreate GUI elements that are already defined in the subVI.
I assume this behaves like passing arguments as in a text based programming languages like the snippet:
def main_vi(x, y, z): # inputs x, y, z
s = sub_vi(x, y, z)
return s # output s
Is this necessary, or can the subvi's GUI controls directly be reused from outside?
Is it possible to use the subVIs inside of an "main" VI that includes everything and maps everything to a common UI using tabs?
Or is it better to copy everything to the main VI, i.e. no code reuse at all?
Thanks in advance!
Depending on the functionality you are going for, yo may want o look into XControls. This would allow you to encapsulate your functionality into a reusable control that could be used on a main panel without making the main panel very messy.
Large UI's can be a pain (pun with pane not intended), especially if there are a lot of controls and indicators. There are some useful ways to break UIs into modular components. XControls are one of those but I don't recommend them due to their unpredictable behaviors. Instead look into working with Sub Panels. There is a great toolkit for this from a company called Moore Good Ideas (or MGI). More info can be found on their website here.
There is also a better alternative to XControls, called QControls. More info on them can be found here.
In general, though, you might want to look into a more modular framework. More info on Frameworks can be found here.
I am trying to brainstorm how to go about creating a program that will be actively running alongside my application and will watch for messageboxes to be shown in the application and take all the information(text, buttons, parameters) included with that messagebox and house them as an object in a global variable available throughout my application.
Is there anyway to tell programatically in my application that a messagebox is about to appear and to take any information related to it and place it in an object? Aside from having to scan the code, which isn't what I'm looking for especially since there's many places messageboxes will appear, this would give incorrect information.
Or is there a better way to go about this? All I'm looking for is information associated with the messagebox that is about to appear(and not show the messagebox then)
Any tips or websites I could reference is greatly appreciated!!!
Create your own class that takes in the same parameters as the standard messagebox.show and then calls the messagebox.show passing the parameters on. When you are ready, you can then put some code before the standard call that will capture the information.
I always create my own messagebox.show so I can control it. It's nice to have a standard title and there maybe time that you need to do special stuff with it, like log the messages.
BTW, because of scoping, if your class is in the same project, yours will be used instead of the standard, unless you fully qualified it: system.windows.forms.messagebox.show().
I maintain an old vb.net project that I didn't make and I was wondering if there's an easy way to determine which parts of the software is still used today by the staff where I work.
I would like to log all function calls without having to edit each one of them if possible.
The project has 27 forms and 6 modules.
Any ideas?
Thanks!
There is no way to 100% determine everything that is used by the system. Vb.Net supports dynamic invocation of methods / properties. Hence you can't even do tricks like delete some code and see if it recompiles. Even if it compiles it could be invoked dynamically.
One way to get a sense of what code is used is to profile the application. Start up the profiler, run the app and go through all of the ways in which the app is used. The resulting profile should give you a good sense of what parts are used. It's very possible though this approach will miss code though
Windows XP
The small company I work for just started using this command-line software and it's rather confusing and tedious. I was wondering if it would be feasible to make a GUI frontend and how I would start going about it.
If possible, I would like to have it get data to fill in dropdown boxes and such, but at the very least I'd like to be able to hit a button and perform whatever task. I have never done anything like this before so any help at all would be appreciated.
Thanks
There are two options here:
If the command line exe calls a dll or assemlbly to do the work, then you can work on a front end for the DLL based on the methods that it exposes (ie you can cut out the command line front end completely.
Alternatively you need to wrap the process that the command line runs in and catch its output, and pass it input as appropriate. There's a guide on how to write such a wrapper here: http://support.microsoft.com/kb/305994 (This one is based on writing the wrapper in c#).
One comment though - while it would be possible to do this in VB.Net using the illustrated techniques, doing it in VB6 would be much harder, or even impossible.
I'm fairly new to VB.NET, and I'm working on a text editor with a tabbed interface. I deal with large text files, so I'm wondering what is the best way to go about this.
Should I have each tab / text document open up in a new thread or a process? I basically want the entire application to always run fast as the text editor is just one part of it. If I have several large text files open I don't want the rest of the application slowing down a bit.
If someone can help shed light on this and maybe point me to a URL with any relevant examples, I'd appreciate it!
Should I have each tab / text document open up in a new thread or a process?
No. Definitely not a new process. The amount of Win32 to put everything back together will make you hate yourself.
Not a new thread either. The Winforms UI runs in a single dispatch thread. Trying to touch the UI from different threads will make your program explode.
I would recommend simply using the tried, true, and boring background worker approach. This can be used with threads or just using asynchronous IO (.NET handles the threading for you). Depending upon your use case you may want to just lazy-load parts of files, you can use memory mapped or random access files (e.g. only read in a very small part of the file at a time). In any case the "data" should be separate from the visualization of said data.
(Emphasis added to search terms.)
Whether you have 1 or 10 tabs open, you will only be able to type/edit 1 file at a time, the other tabs will just be taking up memory in the data structure you define, so not sure how there would be an impact on performance.
As a side note, if you are doing a large amount of string manipulation use the stringbuilder class, far quicker and memory efficient.