Daklu

I guess I haven't been on my soapbox enough for google to pick it up. "Function machine" is a term I coined based on a comment from mesmith here. It is what QSMs should be called because it more accurately describes what they really are. I suggest that QSMs aren't state machines at all. What we commonly refer to as "states" within the QSM don't (to me) appear to be states in the context of state machines in general. (See my previous comment on the soda can.) They are commands to do something, similar to function calls in a procedural programming language. Hence, "function machine." It may be a requirement for function machines. As near as I can tell state machines don't have the ability to pass arguments between states; everything is decided based on the current state. (My understanding of state machine theory is woefully incomplete, so maybe some flavors do.) There are some good articles on state machines here, and this article talks about the difference between Moore and Mealy state machines. Here's a Moore state diagram of a microwave oven taken from the article. (For some reason I can't attach the image inline. Refer to figure at the end of the post.) There are a couple interesting points in this diagram. First, notice the states they have chosen. More importantly, notice what isn't a state. There aren't any command states--no "Start Cooking" or "Ring Bell" states. The act of actually starting the microwave would be a sub vi that runs when the Cooking state is entered. (In a Mealy state machine StartCooking.vi would be set up as exit actions in both the Idle state and the CookingInterrupted state.) Second, notice the state transitions are all (except for the Init->Idle transition) based on changes to the state variables. The state transition follows changes in the state variables. In a function machine the state transition precedes changes in the state variables. I haven't worked through all the ramifications of this but I do get the feeling it is an important difference. The flaws are inherent to the design, so no I don't think they can be eliminated. The impact of the flaws on your app can be reduced if you're really careful. I figure why walk along the edge of the cliff if you don't have to? I think there are better design patterns that are both more flexible and more robust, so why continue to use this one? No, but some are made of glass while others are made of steel. My experience was exactly the opposite. I didn't find the QSM scalable at all--it gets way too complicated too quickly. I'd argue that if you have to stop execution at some arbitrary point in ABXYZ, a state machine probably isn't the right design pattern to use. The restriction only applies if the message receiver relies on messages coming in a specific order, such as with QSMs. If your receiver is a message handler instead of a QSM then it isn't an issue.

This from the guy who turned himself into a gigantic penis in 7 seconds... I'll ask my wife, but I don't think she will be very keen on the idea... Oh, oh, oh... you mean the state machines.... That'll be a little tougher since I almost never use them. When I went through QSM rehab I chose the abstinence path and swore off them. While I was exploring how to convert QSMs into regular (non-queued) state machines, I discovered my application requirements aren't really met by the state machine pattern. So I switched over to messages and message handlers. (One thing I noticed in my QSMs is that my "states" weren't states at all; they were processes. Step back from SM implementations for a minute and think about the states of a can of soda. A few possible states are "wet," "cold," and "closed." If you shake it up and give it to your girlfriend to open it would be in the "overflowing" state. (And she'd be in the "pissed off" state.) These are all adjectives. They are describing a noun. Now look at the state names in your state machine. How many of them are describing a noun and how many are commands to do something? Is "spray soda" a valid state for a soda can?) What's the difference between a state machine and a message handler? In my mind the main difference is when you diagram a state machine you end up with states leading to other states, similar to this. (Ben posted this quite some time ago. I hope he doesn't mind me using it here as a good illustration of a control flow diagram.) Diagramming a message handler results in an asterisk pattern. It sits in an idle state waiting for a message to come. When it receives one it enters the case statement to process that message and immediately returns to wait for the next message. Each message is an independent and atomic operation. There is never a direct transition from one "state" to another. There are also terminology differences that (I believe) exert some influence over how programmers use these patterns. The very nature of state machines is to enter a state, do some work, and choose the next state based on its state at that point in time. That's what makes it a state machine. In contrast, message handlers only handle messages. By calling it a message handler instead of a queued state machine (which it closely resembles when implemented) you are giving it a different role in your application; one that when implemented is less apt to result in a messy maze of mixed-up machine states. (QSMs are the demon offspring from the unholy mating of state machines and message handlers.) Now that my excuses are out fo the way... The only code I have at the moment is some stuff from the first MVC app I wrote a while back. These are diagrams from the process loops of the Model ("Engine") active object and the View ("UI") active object. This particular UI was a prototype I used primarily to test out the rest of the app. It has only 5 buttons and a status bar--not nearly as complicated as yours. (Turns out they didn't really need all those fancy UI things they originally asked for...) In any case, I think this at least illustrates the idea. (In this particular application my active objects receive messages on a queue and use events to communicate to external listeners. Also, you'll notice I was quite liberal with my application of objects, going so far as to wrap every message, event, and the event's data in its own class. Neither of these details are important to the way I use a message handler. In fact, the two loops could be implemented on the same bd without the active objects.) This is the engine's process loop. There are only four messages this loop handles. See that vi in the middle, CalTableEditor:ExecuteCalProcess? Instead of creating an endless list of states to execute each of the 2 dozen calibration processes, all that complexity is hidden from the user here because the purpose of this vi is to handle messages, not execute a calibration process. The calibration process is delegated to the CalTableEditor object. (More precisely, it is delegated to each of the 2 dozen CalTableEditor child classes. CalTableEditor is an abstract class and is never directly instantiated. Each of the child classes is responsible for executing its own calibration process.) I send out events before the cal process starts and after it finishes so the status bar on the UI can be updated. Here's the UI's event structure to handle front panel events. If the user selects a valid calibration file from the dialog box, the path is bundled into a LoadCalFileRequestEventData object and the LoadCalFileRequestEvent is fired. (Whether or not anyone handles that event or what the actual outcome of the load request is doesn't matter to the UI. When something happens the user needs to know about, another module will send the necessary information to the UI. The UI only "decides" how to present the information to the user.) This is where the UI handles messages that are sent to it. Since this is a simple UI there aren't many messages it exposes. If I wanted to disable controls or have other kinds of UI changes I would add new message cases here to do those things. In this example an external module (the Controller in this case) has sent a ShowDialogBoxMessage object to the UI. Contained in the ShowDialogBoxMessage is a child of DialogBox.lvclass. Like the CalTableEditor class, the DialogBox class is an abstract class and the actual act of showing the dialog box is delegated to the child classes. (BTW, this is an example of the command pattern.) This app has six different dialog box styles that can be called by simply using a different DialogBox subclass when creating the ShowDialogBoxMessage object. The notifier is there in case the caller is waiting on a response from the dialog box.

Yank his license? I didn't mean people intentionally trying to screw up the code. I meant less knowledgable LV programmers coming in and making changes that *appear* to be good decisions, when in fact they are introducing subtle bugs that not only aren't noticed, but can't be eliminated without significantly restructuring the app. It doesn't even need to be a coworker; maybe it's a customer breathing down your neck complaining that you're spending too much time on it when the problem would be solved if you just made the quick fix his way. (Some of our internal customers are always telling us how simple it is to change our apps to accomodate their latest request. Occasionally they're right. Usually there are significant bugs associated with their change they're not aware of. There are always structural and maintenance concerns with their proposed implementations.) You mean you're trying to discourage people from using the QSM too!? You sure have a weird way of going about it... Ultimately we're all trying to create good software that meets our customer's needs. Some of our differences might just be due to the different environments we work in. Since I develop internal tools my customers consider my time essentially free. (They're not signing my paycheck.) I'm expected to be able to react quickly to contantly changing requirements. To some extent our tools are *always* in development. We never know when someone will come with a request for "just this one little change" to a current tool. Last night I spent a couple hours going over JKI's state machine template and their 3 button dialog example. (The enqueue state icon is a little too phallic for me, but that's neither here nor there.) The way they've incorporated arguments into the state calls is very clever. On the other hand, the fact that you can even have arguments in your state call indicates it's more a function machine than a state machine. As far as QSMs go it avoids the biggest problem... parallel loops putting states on the same queue. As a top level vi it suffers from the same issue every nested SM has--the UI is unresponsive while states are being processed. No problem if all your state sequences execute in less than a second. Bigger problem if the user hits the Stop button while the state machine is off doing something for the next 20 seconds. And it still encourages having states queue up other states. (Have I mentioned I think that's a bad idea?) Don't get me wrong, I'm not knocking JKI. (Except for whoever created those icons... ) They are arguably one of the top dev houses in N. America, and maybe in the world. Every one of them could code circles around me. They've used that template to create lots of applications that made their customers happy. My point is that with all their experience and knowledge put into the template, they haven't eliminated the QSM's inherent flaws. And let's face it, you, JKI, and anyone else who hangs out here regularly is probably in the top 20% of all Labview users. When using a QSM you know what things are going to lead to problems. My observations are that the QSM is one of the first design patterns users learn once they decide the spaghetti-code-on-a-single-block-diagram technique doesn't work very well. They don't know how to correctly use a QSM. They just know that everyone is telling them to use QSMs. There is very little discussion on the larger issues that have to be addressed to create good software using a QSM. Given that there are so many ways to shoot yourself in the foot with the QSM, I think it is a design pattern best left for advanced users. What's the deciding factor for you when choosing between a sub vi or a state? Me too. I'm on my soapbox due to personal experience, not because I've issued a fatwa against QSMs. (I have issued a fatwa against them, but that's not why I'm on my soapbox.) I agree. But that leads naturally leads to the next step... Why not just create a sub vi out of each of state ABXYZ, and make one state for each macro? The issue isn't restricted to globally available queues. It will occur any time you have parallel loops putting stuff on a queue. If you pull the event structure out of JKI's state machine and put it in a parallel loop on the same block diagram you are opening the door to this problem, even though the queue itself is still private to that vi. The only way to avoid it is to restrict yourself to putting data on the queue from only one branch of data flow.

Yeah, but only 'cause you're staff. Michael is going to have to leave.

I remember previous discussions about that and I look forward to seeing that happen. In the meantime, can you please strip the extensions from the namespaces on labels and other elements that show namespaces to the users? (Dialog boxes, context help, etc. I don't mind it so much in the project window.) I understand keeping track of the extension internally as you need to distinguish between a class and library with the same name. But really, I know my code well enough to understand which modules are libraries and which are classes. (Can you share any details about the refactoring effort?) I hope it wasn't for fear of offending me. I'd much rather have people point out my stupid ideas than let me continue on in ignorance.

Not if you only turn left.

That's just it... in my use case the parent is in memory. Parent and child are members of the same library, but changing the namespace of the owning library by putting it in another library breaks the inheritance. I posted a repro on NI's forums. Looks like CAR 236169 was filed against it. Should be showing up on your desk in a day or so. Damn. I'll buy you a root beer if you can sneak it on there. I didn't exit at all. Save All doesn't fix the error; you have to do one of the two work arounds I posted or manually unset and set the inheritance of every child class.

In your example I actually find the first one easier to read, though it would be harder to find a specific class. The different length lines in the second example make it harder to find the class name, which is what I'm usually looking for. How about this? (I still don't understand why you insist on cluttering up the display with the file extention. Everything in parenthesis must be a library, and everything not in parenthesis must be a class.) A B C (X) C (Y) D (Y) E (X:A) E (X:B) F (X:Z) G (Y:Z) G Z I pulled a Homer with the earlier suggestion of using a tree view to show namespacing. The inheritance dialog box already uses a tree view to show the inheritance hierarchy. (Go figure.) How are you going to have a tree view within a tree view? D'oh!

Yeah, don't anybody bother going to read that announcement, and above all... don't post a reply to the announcement telling them it looks awesome. I actually don't spend much time there, but the bug fixes and auto-save are especially welcome!

I wrote up two lengthy responses to this so far... both of which got crunched by IE. It depends on how complex the parallel process is. For simple processes almost any flavor of Producer Consumer State Machine is just fine. It's the Queued State Machine flavor that causes trouble. As long as you keep the messaging component (to pass data from the producer to the consumer) separated from the consumer's state component you probably won't have trouble. The QSM combines the messaging system and the state system into a single queue, and this creates problems. For more complex processes or if I want to hide the parallel process' internals I'll use an Active Object. Active Objects add a considerable amount of complexity to your system though. If you don't need the flexibility or encapsulation there isn't much reason to go that route. Yep, that's what I was referring to, but I didn't remember the details. It's probably fair to call me a QSM denier. I have a challenge for you. Next time you want to implement a QSM, use a regular state machine instead and restrict yourself to one state for each message from the producer loop. For example, if you have four buttons on the fp, you have only four states (+an init, exit, and an idle state if you want one) regardless of how complex the process is for each state. If you need to use code in more than one state, put it in a sub vi instead of new state. Then compare the 4 state SM with a 20 state QSM and decide which is cleaner. (Of course I'm saying this without having examined one of your QSMs, so maybe yours don't have the problems that most of them do.) Handy, yes, but I've found that for all but the most simple applications they are very difficult to debug. Suppose you put states X, Y, and Z on the queue, but you forgot that X queues up A and B before exiting. Instead of XABYZ you end up with XYZAB. So to fix that you have X enqueue A and B on the front of the queue instead of the back. Now you have XABYZ, just like you want. All good? Maybe, maybe not. Do you have an Abort button that flushes the queue and/or throws a quit state (Q) on the front of the queue? What happens if X is executing when the user hits the Abort button? While X is executing the queue is flushed and Q is put in it. X finishes executing and put AB on the front. Now your queue has ABQ and your application isn't exiting. Pretty soon you have to start examining the queue (and possible maintaining a history of previous states) just to figure out what states you should enqueue next. Application control logic is way easier to follow when it's on the block diagram instead of the queue. I believe QSMs are inherently flawed. They depend on the states being executed in a specific order. However, when you have independent loops adding items to the queue (as most QSM implementation do) you forfeit your ability to guarantee the order will be correct and open the door for nasty bugs that may occur rarely and are very hard to track down. You certainly can be disciplined enough to only enqueue states in your producer loop, but is everyone that works (or will work) on the app just as disciplined? QSMs practically encourage you to enqueue states in the consumer loop--it's an easy way to reuse code. It's hard to pass that up when it looks like an quick fix to a problem. Good design patterns promote good design decisions. QSMs don't promote good design decisions. (The one time a QSM might be justified is if you're doing a lot of operations in the consumer loop that can't easily be put in a sub vi, like using front panel property/invoke nodes. Even in those cases I'm more inclined to send user events from the consumer loop back to the UI loop and let the UI loop handle all the fp control functions.)

I assume the sub vis may also be broken up into many clumps depending on their complexity?

I second Paul's request. If you do go this route, can you please, please, please make the dialog box resizable and have the size persist between calls? And maybe strip out the .lvlib and .lvclass extensions from the diplays? I imagine the extension might be useful if I have a class and library with the same name at the same spot in the namespace, but that happens so rarely (I've done it once) that they're usually just noise. I agree. Figuring out those things is part of what makes UI design so hard. Showing the full namespace in the tree view strikes me as redundant, but having a button on the dialog box to switch between a flat alphabetic view with full namespace and a short name tree view would be worthwhile.

Maybe you can try closing your right eye?

To be honest, I didn't even notice it until I read your post and went to Unread Content to see what you were talking about. On IE the effect is very subtle. What browser do you use?

Yeah, I've noticed that before too. In general I get a bit annoyed when fully qualified namespaces are used--most notably when I drop objects on a front panel. I almost always go back and delete the namespacing and the .lvclass extension from the object's label. (Maybe it wouldn't be so bad if all the library extensions weren't used...) My main issue with including the fully qualified namespace in the dialog box is that sometimes the names get pretty long and the dense text could be hard to read. However, there are definitely times when I want a better way to select the correct class to inherit from. Maybe providing an alternate way to view the classes would help. Instead of just listing them alphabeticly have the option to include the libraries and show the classes nested in the correct .lvlib file? Or maybe instead of showing the fully qualified namespace just show enough of the namespace to distinguish between like named classes? (Either way I'd rather keep using the path than have to wait even longer for LV to respond.)

To add to jdunham's response, in general there isn't a one-to-one mapping of os threads to data flow branches. (I'll use that term for now to avoid ambiguity. Still don't really like it.) The loop may execute on one os thread one time around and on another os thread the next time around. However, I think you can force parallel sub vis to execute in different os threads if you assign them to different LV execution systems. To complicate matters, the compiler creates clumps of sequential instructions, but a clump may include multiple data flow branches. In the bd above SubVI1, SubVI2, and the Add prim may all be compiled into a single clump, so even though SubVI1 and SubVI2 theoretically execute in parallel, they are in fact sequenced and will execute on the same thread. Why not make the clumps smaller so SubVI1 and SubVI2 can really execute in parallel? If the clumps are too small, the program's execution time is dominated by managing the clumps and efficiency goes down. If the clumps are too big you lose parallelism and efficiency goes down. I haven't seen anything that describes how LV makes clumping decisions, so we have to accept that NI's compiler engineers know their stuff. My take away from what I have read is that usually you don't need to worry about it, but sometimes you do. ---------------------- Here are a couple links I found: Advances in Data Flow Programming Languages - A very good article on the history of data flow languages. Ideas in Wiring: How Does Data Flow Execution Work? - A blog article from an NI engineer.

I see now. I misunderstood your failure mode and thought the new namespacing was preventing the classes from being loaded. Yeah, you can have identically (short) named classes in the same project as long as the fully qualified name is different. I'm not wishing for taking namespaces away, I just wish namespaces and libraries weren't so tightly integrated. They serve different purposes. Libraries are a functional grouping of related code. Namespaces are a logical grouping of related code. Lots of times their needs overlap; sometimes they don't. One thing I'd like to be able to do add classes to a library and gain the ability to define scope without changing the class' namespace. (I find this especially annoying since LV doesn't support inner classes.) I'd also like to be able to create hierarchical namespaces for reuse code. Due to the cascading load nature of libraries it's not very practical to do that in Labview. And sometimes I even want a single namespace to span multiple libraries. SpeculationMode.Enter(); In your situation the library is loaded because the .lvproj, .lvlib, and .lvclass files track of their membership by path. When the project loads a VI that is part of a library, the library file is loaded too and becomes part of the project. VIs, on the other hand, store references to other VIs and classes using the fully qualified (namespaced) name. If a sub VI's fully qualified name has changed when the calling vi is not in memory, it's going to be fairly restricted in its ability to correctly figure out which sub vi it should be using. (Whatever heuristics NI comes up with to resolve it is bound to be wrong sometimes.) Come to think of it, I don't think your use case *can* be addressed without decoupling libraries and namespaces. In my use case, it turns out the .lvclass file stores the link to the parent class as a binary string, so it probably also uses a fully qualified name. What I don't understand is that everything is already in memory so why aren't the parent links automatically updated to reflect the new namespace without using the workaround? SpeculationMode.Exit();

Lately I've been reading up on data flow languages in general and Labview's execution system and discovered I have been thinking about things all wrong. Chunks of code without data dependencies can execute in parallel, so over time I have come to associate that parallelism as meaning multiple OS threads are used. It turns out that's not the case. Multiple threads may be used, but are not necessarily used. So that leads to my question. If they're not threads, what do we call each arbitrary unit of code that is free from external data flow dependencies? We often refer to parallel "loops," but parallelism isn't always contained in a loop. Labview documentation refers to groups of sequential operations as "clumps." Those are artifacts of the compiler, not the dev environment, so I'm not sure that's a good name either. "Branch" is a likely candidate. We talk about branching wires all the time. We don't typically talk about a branch as a unit of execution. Plus "branch" tends to refer to what you see on the bd, not an arbitrary chunk of data flow. In the diagram it is obvious SubVI1 is a branch, SubVI2 is a branch, and SubVI3 + SubVI4 is a branch. (Assuming none of the sub vis obtain external data from references.) Notice that SubVI1 + SubVI2 + Add primitive is also a branch, but the term "branch" doesn't seem (to me) to naturally apply to that group of code. Thoughts? Ideas?

Yeah, all my reusable code now automatically goes in libraries. I also often use libraries to partition non-reusable code within an application, such as Model.lvlib, View.lvlib, and Controller.lvlib. I agree there's a lot of room for improvement in this area. I don't think it would be a "relatively minor" effort. I've talked to AQ about it in the past and it sounded like decoupling the namespace and library would have a ripple effect deep into Labview's internals.

I can't give you an exact number, but the answer is "more than you should ever need." To be honest, I think you're basing your decision on the wrong criteria. Events and queues can both be used to transmit data to parallel loops, but they have different purposes. Events are used in a "one-to-many" situation. You have one event source and many event consumers. Queues are used in a "many-to-one" situation. You might have many sources enqueueing messages, but only one consumer dequeuing messages. If you have a "one-to-one" relationship you can use either, but queues are easier to work with. I try not to think of it as an "event queue" because the event structure doesn't necessarily process events in the exact order they were received. (Ton knows more about that than I do.) Plus you have no way to manipulate the "event queue." Think of it as an "event handler" instead. When using events it is better to set up an event structure in a loop to receive events and then send messages and the event data (via a queue) to a parallel loop to do the actually processing. That way your event handler stays free to process events as they come in and you don't have to worry about events stacking up. When is it a good idea to use events? The first is obviously when you have to process the user's fp input. The Producer/Consumer Design Pattern (Events) template is a good starting point for that. I also use events when I'm writing asynchronous code modules as a way to notify clients of things they might be interested in. Personally I haven't found events particularly useful in other situations, mainly because of the edit time overhead associated with them. Uhh... neither. I know lots of people tout the virtues of the Queued State Machine; personally I think it's a poor pattern because it doesn't promote good design decisions. Using a queue to store sequences of states to be executed can easily lead to code that contains hidden errors and is hard to maintain. You can use a queue to transmit messages and data from the UI loop to the Processing loop, but don't use that queue to control state as well.

So I have an ActiveObject library template I copy into projects when I want to use an active object for part of the application. This library contains a dozen or so classes with up to 3 levels of inheritance. Earlier today I discovered that if I add ActiveObject.lvlib to another library in my project, such as Model.lvlib, all the ActiveObject inheritance breaks and I have to go through and relink everything. This is especially irritating when I hit the sticky mouse bug and accidentally remove ActiveObject.lvlib from Model.lvlib. I have to manually relink everything again when I add it back. I'm guessing this is because the classes aren't smart enough to know (or maybe simply can't know) that the parent's fully qualified name was changed when it was added to Model.lvlib. Would be nice if a mass compile would fix it, but that fails because of the broken VIs. I like Labview a lot, but it sure doesn't make component-based development very easy. [Later] I did discover an easier work-around... 1. Add ActiveObject.lvlib to the project, not as part of another library. 2. Move all my classes from ActiveObject.lvlib to Model.lvlib. 3. Move ActiveObject.lvlib so it is part of Model.lvlib. 4. Move the previous classes back into ActiveObject.lvlib. [Edit -- much later] An easier work around is to set the parent class' scope to something else, then set it back to what it is supposed to be. This apparently causes LV to reanalyze the permissions and remove the error.

So I whipped up a little table that correlates the locations from 'Get System Directory.vi' and the Windows Installer variables (used with the built-in install builder) with Windows XP and Windows 7. None of the locations that you can easily get to via Get System Directory and Windows Installer are appropriate for a machine-wide config file. If you create the config file at run time instead of installing it, the Public Documents tag for Get System Directory will work. You can avoid having them show up in each users' My Documents folder by stripping "Documents" and appending "AppData\MyApp\MyApp.ini." It's not ideal, but it's workable. Windows 7 has a %PUBLIC% environment variable that maps directly to Users\Public, but that variable doesn't exist in XP so it's not much help with cross-os compatibility.

Yeah, I believe that location would work for machine-wide data/config files. The downside is that in XP that ends up in the "My Documents" part of the Start menu, which some users don't like.

[Cross posted to NI] Okay, here's an issue that has me completely stumped. I have a third party mixed mode (managed and unmanaged code) assembly that I'm trying to link to from Labview. I've done the usual things, such as creating a unique project file and putting the assembly in the project directory, etc, to no avail. Using the Select Object from Assembly dialog always returns the generic "An error occurred trying to load this assembly." DebugView returns an equally unhelpful error message: "DNError: (3)." The assembly loads just fine in .Net Reflector and I can link to it and compile from Visual Studio. Fusion Viewer (FV) shows that the assembly *is* being loaded... for some reason Labview doesn't know it. Any ideas? *** Assembly Binder Log Entry (6/8/2010 @ 8:57:02 PM) ***The operation was successful.Bind result: hr = 0x0. The operation completed successfully.Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dllRunning under executable C:\Program Files\National Instruments\LabVIEW 2009\LabVIEW.exe--- A detailed error log follows. === Pre-bind state information ===LOG: User = REDMOND\dakluLOG: Where-ref bind. Location = C:\scc\attg dev\DotNet\Instruments\Flashcut\trunk\bin\remote.dllLOG: Appbase = file:///C:/Program Files/National Instruments/LabVIEW 2009/LOG: Initial PrivatePath = NULLLOG: Dynamic Base = NULLLOG: Cache Base = NULLLOG: AppName = LabVIEW Domain for ReflectionCalling assembly : (Unknown).===LOG: This bind starts in LoadFrom load context.WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().LOG: No application configuration file found.LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.LOG: Attempting download of new URL file:///C:/scc/attg dev/DotNet/Instruments/Flashcut/trunk/bin/remote.dll.LOG: Assembly download was successful. Attempting setup of file: C:\scc\attg dev\DotNet\Instruments\Flashcut\trunk\bin\remote.dllLOG: Entering run-from-source setup phase.LOG: Assembly Name is: Remote, Version=4.0.0.15, Culture=neutral, PublicKeyToken=nullLOG: Re-apply policy for where-ref bind.LOG: Where-ref bind Codebase does not match what is found in default context. Keep the result in LoadFrom context.LOG: Binding succeeds. Returns assembly from C:\scc\attg dev\DotNet\Instruments\Flashcut\trunk\bin\remote.dll.LOG: Assembly is loaded in LoadFrom load context.

The advantage to bigger screens isn't bigger sub vis, it's the ability to see more windows at the same time. Programming (in any language) on a laptop is an exercise in frustration for me. Still, I had a coworker with dual 30" dell monitors and that was simply too big for me. Too much head movement required to find stuff. Why not just conduct perf testing on the test computer if you're concerned about run time performance? The LV dev environment can be very resource intensive, especially if you have lots of add-ons and toolkits. I'd go nuts if I had to develop on the low end computers we use for test stations.