Mads

Mee too:-) That way getting notifier references by name - and handling different data types, would be as clean and effective as it could be - and it's a functionality that complements what is already available.

User events will give you much of the "feeder"-logic for free - that's a good idea, however you still need a que manager that lets VIs register their feeds or subscribe to a feed ...The manager would have an event reference lookup table. The point of this is that you do not know how many feeds or subscribers you have at compile time, instead the code will allow you to add these dynamically...e.g. when you create plugins to your application that wants access to a data stream. Ideally this could be something that could be packaged with LV...or OpenG, as it would be a very useful design pattern. Daklu - if there is not too much digging required...that would be very interesting to see yes:-) Mads

Notifiers guarantee that all VIs that wait for a notification will be notified, but they do not buffer the notifications (well, you can get the previous one, but otherwise they are lossy). Ques on the other hand have a buffer, but do not guarantee that all VIs will see the incoming data. If one VI deques data from a que - other VIs that wait for data in that que will miss it (making it rather uncommon to have multiple consumers on the same que). Has anyone made a design pattern that combines the "delivery to all subscribers guaranteed"-behaviour of the notifier - with the "delivery of all data" behaviour of the (non-lossy) que? Here is an example of how you would use such a "Notifier with buffer": You have a loop that measures something every now and then. To communicate the readings you have another loop that takes the readings and writes them to a different app using TCP/IP...You implement this as a producer-consumer pattern based on a que....this way the TCP-communication will not need to poll a list of readings and check which ones are new - instead it will sit idle and wait for new data..great. Later however you find that you want to add another function that needs the data. With a regular que this would mean that you would need to modify your producer to actually deliver data to an additional que.... With a "Notifier with buffer" however, you would not need to change the code of the producer at all. You would just register a new subscription to "Notifier name" - and voila, your new code has a lossless stream of the data it needs. The fact that you do not need to edit the producer makes it possible to add such expansions to built applications, if you have given them a plugin architecture. Realising this idea would e.g. be possible by making a Que-manager that pipes data from incoming ques out to multiple subscriber ques. Whenever you have a producer of data - you create a que and give a reference to it to the que manager. If a VI wants to subscribe to the data, it aks the manager, using the name of the que used by the producer, for a reference. The que manager looks up its own list of ques - and when it finds it - it creates an outgoing que and gives the subscriber that reference. It also adds the subscriber to a list it gives to a dynamically created feeder. A feeder VI would be a VI that waits for data from a given incoming que (producer) - and then writes that data to its list of outgoing ques... So far I've only played with this idea..and perhaps I'm overlooking an already existing alternative, or a big flaw?

Absolutely Rolf, if anything I would call using DDE this way now a kind of security through obscurity..I do not blame you for laughing Everyone notices if an application opens a TCP-port, you even get a nice warning from the Windows firewall. Most apps I make are servers (so I do not avoid the warning anyway...) I could have just added the command to the existing set of commands supported by my client-server interface...however it does not seem like a good idea to have such a thing available.If I had used TCP I would put this on a separate TCP port and make sure that port would always stay blocked in the firewall and had some password protection that "only" the launcher would be able to pass by accessing local information. There should be a better option for local communication....I can think of a couple, but neither of them are elegant... Mads

With the events I mentioned - cursor move, window resize etc. you do not need any of the intermediate events, the really important event is the latest - that is the event that tells you where the cursor was moved last, how large thw window is now etc...and previous positions/sizes are of much less interest....so I do not understand why you see significant problems...after all this would only be a setting that you could active for the events it is suitable for.

This goes for all similar events - like the cursor move event, or the window resize event e.g. - the GUI will be affected by how quick the event is handled. This is why I typically just set a flag in the event case and then do the processing of the event somewhere else. The ideal solution would be to be able to set the event structure to have a lossy buffer..i.e. it should only keep the latest unprocessed instance of the event, not stack them up. (It has been proposed on the Idea Exchange already).

Yes, you have a helper executable - that's what I call the "Launcher". When the whole application set is installed it adds entries to the registry that associates certain files with the Launcher...This way the OS runs an instance of the launcher...which in turn runs (if necessary) and transfers the file path to the main application. I have extracted the core of the code and attached it here... I have *not* taken the time to make it into a fully working example as that would take more time than I have right now...but you should be able to pick up the main ideas. OpenG VIs are required... It is about time that we get full support for file associations in LV..so Kudos that idea on the Idea Exchange everyone, please. Mads File Launcher Example.zip

I do it this way in my applications. The loader app gets the file path from the argument generated by the OS due to the registry settings - and uses DDE to transfer the path of the opened file. If the DDE connection fails it assumes that the app is not running yet and starts it...and waits until it gets the DDE link. I do not launch the target app with arguments simply because I want it to work smoothly when opening multiple files: I have set the .ini file of the launcher so that it runs multiple instances (AllowMultipleInstances=True)...that way people can open multiple files in one go. The reason why I chose DDE instead of TCP is because it is less of an open door to the outside world...although I would prefer it if there was indeed a way to esnsure that the communication was only possible locally on the PC (without using the firewall). ActiveX could be an option...as DDE really is a very old technology and might get phased out soon. Mads

I'm waiting for the Developer Suite first....we use VLM as well (does anyone know if we need a new license file and when the upgrade DVDs will arrive? We just received new DVDs that still had 8.6.1...waste.) One question that those of you who have installed it already might know; is it possible to build 32 bit apps in LabVIEW 64bit? We'll probably need to support 32 bit systems for a while, but it would be nice to run the 64 bit version of LV and just have it as an option to build the app as 32bit.

Hey, thanks - I got around the glyph by editing a ring control after all...but then I had not noticed that they can click the glyph as well in VIPM. The part I missed in this case was the "-" though...I tried _ .... Thanks again!

In VIPM there is a GUI element I'm curious as to how they made: the LabVIEW version and Filter by installation status rings - end the search box. They all have glyphs next to the text...and in the former there are separator lines between some of the entries, just like in a menu... One way to get the glyph is to edit a Modern style menu ring and replace it's arrow element...(and replace the rest with system style elements) but the arrow is moved with the right side of the control so that get's messy if you want to rescale the control... Any tips (or a new article on the How did they do that page on the VIPM site:-))?

If all you need to resize on the front panel is one graph then right-click on that graph and set it to scale with the panel. In order to ensure that other controls stick in their correct position and/or relation to eachother you can group the controls and/or control where they stick by placing them in or outside the right quadrant of the scaling frame of the graph. If e.g. you want them to stick to the top of the scaling frame the group of controls need to have at least one element that is above the top of the resizing frame. In cases where you have multiple objects that needs to resize the solution is splitters. You can adjust the thickness of the splitter - if it is only a couple of pixels it will in fact not even show when you are running the VI...It's often OK to have the splitter visible though, tells the user something about how the panel will behave. Mads QUOTE (Michael Malak @ May 27 2009, 12:26 AM)

We used to have a poster at the company where I work that said something like: "For every existing customer you lose you have to recruite 10 new ones to compensate". It may not always be true, but I think it's a very good rule to operate by. One small thing that could improve LabVIEW in this aspect would be to let users choose between a set of user profiles during the installation process (for those of us that have Volume Licenses it would be nice to have an *easy* way to include our own such profiles in the installation sets as well), that way we would not need to repeatedly deal with the "Express mode" that they have chosen to be the default. QUOTE (hooovahh @ Apr 16 2009, 02:37 PM)

The MGI VIs are in fact just as slow as the OpenG Config file VIs on my PAC units. The OpenG VIs have their main weakness in the use of a recursive call. The time consuming part in the MGI Read VI is the "Get Type Info.vi"...which has a locked diagram so I am unable to investigate it any further... QUOTE (Yen @ May 27 2008, 07:05 PM)

As previously mentioned the resolution is decided by Sample rate / number of samples, if e.g. I sample 2000 samples at 4 MS/s the resolution will be 4000000/2000 = 2000 (Hz) It is possible to improve the situation a bit by zero padding the signal though, this is often referred to as spectral interpolation. Let's say that you have sampled 2000 samples - prior to running the FFT you add n * 2000 zeroes to the sample array. If n =1 this will double your resolution...however we are really just talking about an interpolation effect here so there is a limit as to how much you actually gain. Mads QUOTE (Maci @ Jan 30 2009, 04:39 AM)

Superb, your base64 code did the trick, thanks As for the weakness in the unzip-function I tried downloading the latest version (mine was the previous version) and to my luck the issue seems to have been adressed there, so now absolutely everything works as it should :thumbup: :thumbup: PS. The OpenG base64 decoder still has this problem, that code is not maintained anymore (I think(?))...so replacing it, e.g. with Mark's code, might be useful for others as well. Mads QUOTE (mesmith @ Jan 15 2009, 02:54 PM)

I am using the Open G POP functions to fetch and decode e-mails with attached zip files, and have run into a rather "fun" combination of errors: 1. If the (zip) file has two zero-bytes at the end it will be reflected in the base64-encoded data, however only one of them will come through when the OpenG base64 decoding is applied. 2. If a zip file lacks that final zero-byte the OpenG unzip-functions (i.e. the dll they use) will crash. So - in my case my code receives and writes a zip file, and that zip file is read and decompressed just fine with other zip-software, however because the same software is trying to use the OpenG unzip function it ends up crashing the whole software.... I can probably figure out a way to edit the decoder so that it does not lose any bytes (perhaps this is a known issue that is routinely solved?), however it is still a bit uncomfortable to know that the unzip function is possible to crash by feeding it a file with such an error. Mads

Sure, if the drawing code was made into a general API then I would buy it... For graphs you could have an API where all you needed to do was to feed a reference to the graph to a VI from the tool...and voila - now you can draw figures and write text on the graph. :thumbup:

A sidetrack...but anyway: In the UML Modeller you have a drawing tool that would be great to use for other purposes. In my case I need the ability to add text comments, arrows, boxes etc. to a graph...as part of a report tool. The picture properties of the graph control makes integrating the picture and the graph simple enough...but I still need code to handle all the objects so that they can be moved, resized, deleted etc. I assume you do not have any plans on making that part of the package open source ... ExpressionFlow has a good example that lets you draw multiple figures and delete them sequencially, but are there anyone who has made a more complete drawing package in LV that is available for others?

You communicate with the Hilscher card by calling the Cif32dll.dll. The first step is to call the function DevOpenDriver (stdcall) and input the card device number (you can set up the profibus network in Sycon first). The next step is to call DevInitBoard(), the parameters there is the same device number and a text you can set to N/A. Reading and writing to the bus is done using the DevExchangeIO function: Data transfers are done in blocks of 32 bytes typically so you need to split and write or read and join multiple blocks. You can find details about the dll from Hilscher.

It is a good idea to decide on a minimal resolution you want to support and design everything to work there and scale upwards. Depending on the GUI you may allow the users to scale the window down from there as well, but at least put in a minimum to ensure that none of the objects that are set to scale get too small to be used. It can be frustrating to work on a small control panel when you have so much screen real estate, but the diagrams can still be as large as you like...although personally I think it is a bad habit to allow those to grow too large as well... Generally I never scale buttons and numeric controls...most of the dialog controls are typically kept at a fixed size in other applications so I stick to that standard behaviour. The important thing then is to group the objects and place them so that they do not change their separation or location during window scaling. A graph on the other hand e.g. is a typical object to scale with the window. If I need to scale multiple objects properly it can work to group those objects, however a more robust solution is to use window splitters. Truning on the "Maintain all proportions" or the "Scale all"-option is way to crude. Mads QUOTE (dannyt @ Oct 23 2008, 10:07 AM)

The search could be made binary instead, that would cut the number of Nth line calls dramatically... QUOTE (normandinf @ Sep 20 2008, 02:38 AM)

I second your request. I have several applications where the lack of this feature forces me to use a less than optimal GUI...

I've got LV CDs all the way back to 4.0, however is it really the run-time you want? If you want to see the code and not just a running application you will need to install the development environment.

This is not a bug, it's the established way LV decides the order in which to do things: If you have a property node it will execute the actions on it from top to bottom. All you have to do in the first case is to swap the positions of the properties. QUOTE (Aitor Solar @ Jul 15 2008, 12:06 PM)