text editor loading multiple large text files - multi threaded - vb.net

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.

Related

Include a large amount of SubVIs in a main VI

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.

Labview Program changes behavior after looking at (not changing) the Block Diagram

My Labview Program works like a charm, until I look at the Block Diagram. No changes are made. I do not Save. Just Ctrl+E and then Ctrl+R.
Now it does not work properly. Only a Restart of Labview fixes the problem.
My Program controls two Scanner arrays for Laser Cutting simultaneously. To force parallel working, I use the Error handler and loops that wait for a signal from the Scanner. But suddenly some loops run more often than they should.
What does majorly happen in Labview when I open the Block diagram that messes with my code?
Edit:
Its hard to tell what is happening without violating my non-disclosure agreement.
I'm controlling two independent mirror-Arrays for Laser Cutting. While one is running one Cutting-Job, the other is supposed to run the other Jobs. Just very fast. When the first is finished they meet at the same position and run the same geometry at the same slow speed. The jobs are provided as *.XML and stored as .net Objects. The device only runs the most recent job and overwrites it when getting a new one.
I can check if a job is still running. While this is true I run a while loop for the other jobs. Now this loop runs a few times too often and even ignores WAIT-blocks to a degree. Also it skips the part where it reads the XML job file, changes the speed part back to fast again and saves it. It only runs one time fast.
#Joe: No it does not. It only runs once well. afterwards it does not.
Youtube links
The way it is supposed to move
The wrong way
There is exactly one thing I can think of that changes solely by opening the block diagram.
When the block diagram opens, any commented-out or unreachable-code-compiler-eliminated sections of code will load their subVIs. If one of those commented out sections of code were somehow interfere with your running code, you might have an issue.
There are only two ways I know of for that to interfere... both of them are fairly improbable.
a) You have some sort of "check for all VIs in memory" or "check for all types in memory" that you're using as a plug-in system. When the commented-out sections load, that would change the VIs in memory. Such systems are not uncommon when parsing XML, so maybe.
b) You are using Run VI method for some dynamically invoked VI to execute as a top-level VI, but by loading the diagram, it discovers that it is a subVI of your current program. A VI cannot simultaneously be top-level and a subVI, so the call to Run VI returns an error.
That's it. I can't think of anything else. Both ideas seem unlikely, but given your claim and a lack of a block diagram, I figured I'd post it as a hypothesis.
In the improbable case someone has a similar problem. The problem was a xml file that was read during run time. Sometimes multiple instances tried to access it and this produced the error.
Quick point to check: are Debug and "retain data in wires" disabled? While it may not change the computations, but it may certainly change the timing of very tight loops, and that was one of the unexpected program behaviors, OP was referring to.

Labview diagram creation API

I need to drive a testbench with labview.
The test scenarios are written in a languages that can be automaticaly translated into labview diagrams.
Is this an API that allow to create "labview diagrams" from another software ? or with labview itself ?
I agree that LabVIEW scripting is one approach, but let me throw out another option.
If you are planning to do a one time migration from your test code to LabVIEW than scripting is great, but if you plan to regularly update your test code (because it's easier to use the "test" language than LabVIEW) than it could become quite painful to constantly perform the migration every time your test code has changed.
I've had great success with simply putting my state machine inside of a for loop and then reading in "commands" from a text file that was generated using my "test" language (see pic).
For example, to do an IV sweep my text file might say something like:
SourceV, 5
ReadI
Wait, 1
SourceV, 6
ReadI
This image is greatly simplified - I'm not using a state machine and I don't show how to use "parameters," but I can provide a more comprehensive example if needed. Again, I've had great success doing this with around 30 "commands" controlling multiple instruments and then I generated the text input using VBA or Python.
It's called LabVIEW scripting. You will need to enable an option in the VI Server page in the options dialog to see the relevant features.
A few things to note:
Scripting isn't complicated, but you do need to be aware of how LV code is built.
While scripting is public, it was initially created as an internal tool. There are still corners of it which are incomplete.
Scripting code can be tedious. If you can get away with it, try creating templates of code.
NI has something called CodeGen, which I believe are a series of functions which make some scripting easier, although I never really looked into it.

How should I organize my vb.net GUI?

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!

Best strategy to read file only once at launch?

I am reading a file datafile at the launch of my application.This is just self learning drill.
On apple developers website under the heading Minimize File Access at Launch Time
it says
If you must read a file at launch time, do so only once.
So my question is that is there a standard or preferred way of doing this. At the moment I have an instance varible NSArray and I populate that in - (void)viewDidUnloadand never garbage collect it. Is that good enough ? or Should I be making use of application Object (I am not even sure if it is logical to say this.).
There is no standard way to optimize. But there are some guidelines.
One basic idea of optimization is to do less. E.g. as the advice you cited where the data of a file may be needed at multiple points in your code, it is better to read it from disk once and then distribute a data pointer within your program.
If the file is big enough to cause a stutter when you start your application, i.e. it takes more than 20ms to read and parse the file, you should consider reading the file in a background thread/task and adding a ‘loading…’-state to display to the user.