0_o

I already learned the context of his post and it was still nice to get an overview. However, if you don't know any of the subjects in my title and you already have some LVOOP experience I think this is a very good video.

I know it is Kerry but this post gives him the title King hands down

You probably read ElijahK's presentation already: https://decibel.ni.com/content/docs/DOC-21441 However, did you know he added a 80 minutes video about it? : http://zone.ni.com/wv/app/doc/p/id/wv-3364 Amazing! What I would like to see now is an example of a Spaghetti code being converted part by part into such a project. You can call it "The evolution of pasta" Besides that, if the presentation didn't include NI measurements but rather a HAL that contains more general tools like DIO/AIO and different implementing cards while including the singleton design pattern and taking into account dependencies between DIO subsystems, for example, it would be perfect. Oh, NI should also speed up this video's internet connection. Thanks ElijahK.

geoffrey, the basic problem with your code is the path you specified. The regular path of a vi inside an lvlibp will look like xxx.lvlibp/xxx.vi. However, in order to access it you need the path generated by the block: "get exported file list.vi" from programming -> file io -> advanced file functions -> packed library. The path generated from there will look like xxx.lvlibp:xxx.vi. The ":" represent content of a containing file which is logical since you can't see in the explorer a file named xxx.lvlibp/xxx.vi.

CRelf, the plugin architecture Aristos Queue referes to is the one I based my example (posted on page 1 of the thread) on. Instead of going over the link and learning all the pitfalles you could simply use my example and replace the code with yours inside the lvlibs. I gave this same solution with a full implementation. There is info here that is lacking there: how to share a db between two plugins. My example solved it.

Wow!!! I can't disagree more with what is said here and in Ben's post (very rare). Where should I start? 1. Ben's solution handles only the passing of control refs that are relevant to subvis from a localized FG. There is no advantage to doing so instead of passing the direct vi ref since it neither prevents races or dead refs. Besides that, this has nothing to do with a GUI Handler if you mean Model-View-Controller since not all of the control refs are handled and it is all being done manually. What happens if you want to change the GUI or load a sub panel? 2. drjdpowell asked the right question: what is the purpose of the GUI Manager? If you write a small project (less then 50 classes and 200 vis) which is non commercial with just a single team member then you don't need to invest in architecting a MVC with plugins loaded into subpanels. In this case I would suggest you run a recursive script that will drill down into your GUI and save all the control refs at the start of the main vi and pass the result to all the subvis. However, if you are using LVOOP and break the data flow you might turn into some race conditions. If you need future flexibility of the GUI and logic for fast development and logic decoupling between several team members under a large commercial project out of the feasibility faze I think you need to build a plugins+UI Framework architecture and most important a Hardware Abstraction Layer if your hardware might change and MVC if your logic is constantly in R&D faze. Otherwise you will invest in a system that will turn into a spaghetti code that only its first developer could manage and even he/she won’t be able to handle a fundamental upgrade. 3. Paul_at_Lowell described a FP coupled to a control handling logic that communicated with the rest of the logic and model state by messaging. This is a good design since the important issue here is to let the logic with all its subvis/classes/projects/plugins work on the state of the model that can if you want it to synchronize with the GUI. However, I have two problems with this description: he confused the goal of the MVC by requiring a "fast GUI". If his FP acts as a model out of sync from the main model since he requires that the user could change controls ASAP he is actually breaking the MVC. Besides that, you can analyze an application as a production line (I prefer this over a data flow once we have LVOOP). If he first collects UI events, send messages to the logic that in turn updates the model and then sync it with the GUI you can see that we have a dependency of operations and it doesn't matter if he located the sync operation in a coupled BD of the GUI FP or in another vi. Besides that, he also wanted to develop the GUI fast. The more coupled code needed in vi that contains the GUI the slower he will develop it since this logic is manually configured and depending on the particular GUI. The best way to get a GUI design for a new feature is by letting the user play with a FP and to comment each functionality he/she needs, give that design to the R&D for evaluation and requirements documentation and analysis. Then the marketing and management will set the time table and which sub features will be implemented. The user will evaluate and agree. Now, this FP vi with no BD is both your GUI and your requirements documentation. Besides adding a recursive read of all the control refs, initializing/saving state and other common reusable code there should be nothing in this vi. Moreover, as long as you keep the same control names but only change the appearance and organization of the GUI you won't have to change a single thing in the rest of your code. Even removing a control might require no changes. There will simply be a redundant section in your logic. Adding a control requires change but a very simple one that most of it can even be scripted. Anyhow, if I understand correctly, all you want to solve is the same thing Dan07 posted and answered by Ben. In other words, you just want to be able to create a subvi without problems of endless control refs and control events (that you didn't talk about yet I think is important for you since you can't pass them into subvis). For a small/medium project I would do the following: 1. wrap the vi inside a class. 2. copy all the FP into the class control 3. create member access vis for all the class controls. 4. pass the class into each of the vis as a DVR so they could all manipulate the data inside an in place structure. 5. only the main vi needs to handle control events from the GUI and it messages the next step into a relevant queue that the interested subvi checks. 6. inside the write member access vis of the class call a special vi that has the GUI control refs and updates the relevant control by name. 7. the result should be many vis that all get the class DVR which contains the db/state of the modele, manipulate it with no races inside an in place structure while the main vi only initializes and message out (not in) events while maybe blocking UI actions until the logic comes back to the idle state.

crelf, I added to the solution I posted on page 1 of this thread a filter block that adds the dependency to lvanalysis.dll to the plugin1+2 and to the caller. The result was a common lvanalysis.dll for both plugin1+2 lvlibps and another version in the caller.exe inside the data folder. It works just the same. Those 2 dlls apparently have the same name but actually they have a different prefix. You can learn how the LVLibP does it and do it manually without the lvlibps if you like to but I think that is both funny and redundant. Does it answer all your needs? ShaunR, dlls are indeed interesting. I don't think it solves the 32bit/64bit much better or that it is much more stable or easier to manage and update once a change is made, however, for a simple vi that only executes a basic operation, it is quite lovely. I somehow didn't check the dll options till now. Moreover, I just saw that there is an option to create RESTFull web services Anyhow, if you think the dll solution is as complete as the LVLibP functionality could you please update the version I posted (the callee part) to create dlls that I then could call from the caller? I want to see what will change and if the shared db class will be the same between the plugins. I tried doing it myself but I wasn't able to create a dll (I'm probably missing something). Thanks.

That doesn't come as a complete surprise and it is a bit off topic. Lets say you were using a driver which is 32bit but you also have another version which is 64bit or for a different platform. You would have to build a different distribution for each of those cases no matter what tool you are using. LVLibP is actually an advantage here since all you need is to rebuild all the LVLibPs according to the hierarchy and your application will run on your device. A simple script can do it and an automatic builder is the place to put it in. BTW, if someone needs me to convert the code to LV8.2 please ask.

As I promised, attached you can find an example of my solution. In order to execute: Open the zip file, double click the Caller.exe file, fill in the exact directory of ...db version 2 for crelf\builds\Callee Project, run. Feel free to ask for any further clarification. Enjoy. db version 2 for crelf.zip

Ton, you are right, this is off topic since the problem is not with gesture events but with the question: can each finger be designated to a different application while both are frontmost and active and each reads the events from the relevant finger and not from the other one. From the great material you and ShaunR sent me I guess it is an OS limitation and it is impossible at the moment. Thanks.

Can MS Mouse Mischief or Multitouch allow me to use a single very strong computer with multiple screens to allow several users simultaneous work over the computer? For example, instead of buying 4 computers, one for the dad, one for mom, one for the son and one for the daughter, will it allow me to buy a single strong computer with extended desktop over 4 screens that will allow each member to manipulate a different program simultaneously? It is probably just my longing to the MainFrame days but I really wish this was the case instead of having to support and maintain so many pcs even at home when I come back from work.

Hey crelf, I'm short on time and I didn't even have time to open your example, thus, I hope I understood your question good enough. I think I'm doing about the same thing and yet I don't have to play with any namespaces and it works just fine. I guess the main difference between your implementation and mine is that the callee in my case inherits from a class contanied inside the caller, however, I'm not sure if this is the reason my case works and yours doesn't. So, I'll try and describe what I did: 1. my caller is a version of the UI Framework https://decibel.ni.com/content/docs/DOC-15014 2. my callee is a LVLibP plugin that inherits from a generic class that is conained in the caller's project https://decibel.ni.com/content/docs/DOC-19176 3. I pass the status of some subject through a db class (created in the caller) through the connector pane of the callee which while it is being loaded in the callee http://lavag.org/topic/15712-best-way-to-share-data-from-different-subpanels/ see my post there P.S. - this design is in progress and my boss told me this part of my design works in the deployed version. I didn't see it working with my own eyes until now since I'm busy with some other project at the moment. We posted at the same minute and I didn't see mje's post I too had some trouble with the LVLibP's at first but it truned out to be a driver problem and once set they work smooth. I love them!

I don't remember where exactly but it is similar to what bmoyer just said. However, this had a solution while this new problem is much more risky. I thought it was a class mutation history issue with typedef clusters yet from the snapshot it seems as if they are not typedef at all (unless it is an old LV version which I guess it is not).

I heard that dynamic dispatched vis has problem with separating compiled code so I wrote a script to exclude them. I just finished writing the script that goes over all the vis and searches recursively for strings/paths that contain ".vi" in order to remove dynamic loaded vis from a list of vis that will be changed by the script. However, you stopped me at the last second from pressing run and changing all the vis in the list to separate compiled code since I both use LVOOP classes and typedefs, obviously. Can this problem be connected to the mutation history and the issue with cluster typedefs in the class control? Do you know if reentrant vis has problem with separating compiled code or any other issue? The last thing I need right now is to revert my entire project (>2000 vis and lots of classes) after two month of work since some enums changed and I don't know which or have time to check.

It should be an IDE feature yet there are cases we need this feature in our own deployed apps. If your application uses a secondary window to show a graph or a ccd, for example, then you would like to make it easy for the user to find the right window. It could have been awesome if NI implemented it in the IDE and gave us hooks into the system. However, even though people asked for this feature repeatedly, they never implemented it for some bizaere reason, thus, it is up to us to implement it.

I think this feature can be very useful: At the moment all the open LV windows look exactly the same no matter if they are BD or FP or even if they were opened from different LV versions. Once this option will be available we could have a list of open vis with the icon from the connector pane next to each vi with different background color for BD and for FP and a number with the LV version. Besides that, we could have a preview of the vi and even an option to see its status (running/broken/clone/properties/type).

I would try one last thing: copy the vi that causes the trouble to another new vi and remove any advanced GUI controls (silverlight, customized...). If this doesn't help copy it part by part and check when the leaks start.

Hey Daklu, I finally had time to check the this interesting post. Your code looks very nice yet very different from my solution. Once you posted your implementation I understood your question much better and I see that my version had a similar problem. Thanks! Even though the Logic and Model of my MVC wouldn't change after the 4th click the UI loop might still send user actions that won't be reflected and create a difference between the UI and the Model. I guess I need to add a semi logic loop to the UI loop called: "instinctive common UI behavior" that will have to handle such fast cases while interfacing between the UI msg queue and the logic msg queue. Once added the difference between your solution and mine will be that the 5th click won't require a LV thinking proccess (the pointer mouse turning into a loading circle). I would love to post a sample as you requested, however, I'll have time to attend to it only at the end of June. GOOfy Wires.

I might be missing here something since I think the solution is very simple and as Daklu says: "If the solution looks simple, I don't know enough about the problem". Here is how I would solve it: Running an async visitor design pattern with db class input to all the called objects. The db class is passed as a dvr and actions on it are done using the in place structure to avoid races. The db class contains: 0. a dynamic user event to the needy vi event loop. 1. relevant information to this part/topic of the code. 2. member access vis with write that increments an update counter. 3. a counter update member access vi that contains in the write a check for scenarios like did all observer object update their data or did someone specific update or was something specific updated. 4. this last member access vi "write" will trigger the event of the needy to check the result once requirements are met. Thus, I send the dvr db data to all objects and they update the section relevant to them. If the in place is not enough to prevent races since the manipulation must be serial I can add a serialization mechanism or wrap the entire objects code in an in place structure. Once the event is triggered the needy will check the result and destroy the dvr. If you want to send along a future/why block for general analysis or results in a general event case it is also possible and I would use an expert system to define rules over those scenarios. Now, please tell me what did I miss

You need to clarify first what kind of testing you want to do. If it is regression testing over a framework with unit tests it is one thing (TestStand). If you want an automatic machine that tests something in the real word it is something else (HAL+MAL). If you want to virtually test SW with stubs to allow for a much faster development it is again a different task (Command design pattern in the ASL level that records input/output along UI actions). If the tests are predefined with good requirements it is one thing (unit tests) but if you need an expert to explore the functions and create tests on the fly it is something else (UI record + analyze + replay mechanism). Also, if a computer can analyze the results and you can easily write automatic analysis functions then you have an easy scenario. If you need image processing you might have a bigger problem. The logic of each of those options might contain a state machine or a command design pattern with messaging between actors and it might be a good idea to combine all the methodologies if you have the time and money. As for the logic of the state machine, if you are talking about a large scale application I would conceder integrating a parallel UI state machine + Command/Actor state machine + Messaging mechanism with a fuzzy logic rule based expert system (I didn't try it yet in LabVIEW but I'm going to soon enough). Anyhow, the first thing I would do is make sure my boss takes into consideration the need for supporting applications and frameworks that it takes long time+money to choose/develop. Good luck.

rolfk, I just want to emphasize the different uses of a logger and a recorder. A logger is used for debug. You log just the relevant information in order to understand what happened and for this you'll need to parse the log and follow it. A recorder records all the input/output in the ASL level so you could simulate the operation of the system without having it at hand. You don't need to parse a recorder. You use it to verify that the program you wrote still works as expected and develop new features assuming the system gives you a specific response you got in the past. There is a place for logging and there is a place for recording. I find loggers to be useful for parallel loops (if you write good parallel code there is not much use for them) while recorders are very useful since they shorten the development time and add a very easy to implement regression testing. Aristos Queue, thanks! I'll write back after I get the chance to test it.

Tim_S, you can read about my basic MVC design here: http://lavag.org/top...dback-required/ In my design the UI loop only sends messages to the control loop, it is a one directional queue of user generated events. The FP controls are updated from the control loop even from dynamically loaded plugins like Actors or LVLibPs. This is accomplished by a preliminary traverse scan of the main FP, saving all the control references and passing them to all the plugins among other common data using a db class. Notice that in my design each FP control has a replica in a class control and thus, the FP is not being used as a db for the control operation. Once you have the reference of the tree view you can do all that you want to do. Besides that I use the PropSaver to load/save property combinations. By using a direct update (the update is handled by the write property node of the parallel FP control in the class control) I can defer FP updates forever. P.S. - the design from the post is old and was much improved since but I'm still not sure if this methodology has some drawbacks like forcing the FP into memory in the plugins when you use property nodes on the control references or making the property nodes run in the UI thread, maybe ShaunR can answer this. However, if the FP doesn't need many updates (real time graphs) I think I prefer my design even with some drawbacks since it is clean and easy to maintain.

Hi Aristos Queue, Thanks for the risk you taken here! While searching for a solution I went over most options I could put my hands on and this was one of the winners. It gave me some trouble in freezing a vi since it tried to record something and I didn't take it into concideration and as for dynamic vis, it misses the point for HAL which is OO and in some points reentrant. If this feature was working correctly it could have been a solution and a very nice one too with just a little bit of a framework to wrap it up. P.S. - if we talk about unused/depricated features I came across some property nodes for code coverage and other cool stuff like convert to vhdl that I didn't know LV could handle. I understood they are volatile but now I see even some right click features are risky. P.S.2- now that I think about it again, I can use it to record only the lowest level that uses driver blocks and match it with the call chain and the control combination. This might just work since those vis are static non reentrant (even singletonian) !!! Thanks!!!!! I'll post back once it is tested.

Hi Brian, I didn't expect the developer of HAL to answer my questions here. Cool! I would love to see an integrated version of MAL over HAL with integrated OO testing and bug fixes. However, my question regards a different subject: A good simulation will have to record a sequence of high level UI actions and understand which low level MAL/HAL action was taken so it could record a sequence of actions, record the relevant inputs for each action and finally play the responses for virtual UI actions. This process should be general and not feature specific. At the moment I need to write specific record and replay for each feature. I'm searching for a general solution that will listen to the UI and add record replay to the lowest level of the DSSP and thus simulate all the high level actions at once. All the high level (no driver/communication access vis) should be the same in the simulation mode since I'm actually trying to debug them. The lowest level should get a flag with a link to the relevant recording it should run if this is a simulation mode for a specific action that was recorded. If I need to maintain a parallel simulation class I lose all the point of having this simulation mode. I'm trying to understand what you think I should do according to your last paragraph and I still don't understand how you are going to match together the recording to the UI action. A Stub/Mock doesn't just replay a black box, it allows a simulation of UI actions while replaying the relevant response to each specific action. Thus, if I reorder the response to move up, move down, roll over and howl I can ask in the virtual mode to do each of those actions in a different order even though some use the same DSSP vis and each time those same vis were called a different recording was run according to the action we simulate. Thanks for the replay! P.S. - I would pay good money for a good NI platform that will build Mocks/Stubs while adding some CI testing capabilities to a MAL/HAL design along some automatic builder in LabVIEW.

Hi, First, I think there should be a main topic called testing instead of TestStand or along TestStand. I implemented a Hardware Abstraction Layer as described by NI and I think it is poorly designed for the following reasons: The ASL (application separation layer - API for general HW access) is not OO and lacks logic, error handling and stubs/mocks for simulation. I found that during my app development I waist a lot of time since my HAL has no good testing framework with code reuse and each test unit needs all the system to be configured and running. Besides that, if I have no access to the hardware it is very hard to develop since I need to write code, compile it, move it to a test machine, run + debug, come back to LabVIEW and try to find the bug with no live input for LV debug tools and without being able to exactly reproduce the scenario from the test machine. This process will repeat itself until I'll build an ad hoc recording mechanism which is not reusable for other features I develop. Thus, I wonder, do you guys have an agile solution to this bad methodology? Is there a tool that will automatically create some Mocks/Stubs to my code (stub is a recording of the application actions and responses. It can be used to virtualize the environment while actually working on a stand alone application. Thus, testing and development time is reduces). I wrote such a recording mechanism for some of my features but it is not general or integrated into the HAL design I copied from NI. Thanks in advance, GOOfy Wires.