hooovahh

Wow this is a lot of fun. So I have code now able to move and resize the images by updating the style attribute along with the new image data sent. Other control moving and resizing isn't done yet but could be. I also updated the Select class to support changing menu items. This means if you have a Ring with 3 things in it, you can update it with a property node to have 3 different things, or 4 things, and the select item in the web page gets updated. I also worked on reducing the amount of data sent. Right now on the refresh interval all data is resent, and for images that don't change often that is a lot of wasted time and resources. So if the data hasn't changed from the last sent data it doesn't send it. The exception to this is on the first load of the page it requests all data. I'm not going to post these changes just yet, I'd like to see if there are any other bug fixes or features I'm going to implement first. Once again thank you so very much for getting this started, so much useful code in here, and having it be open is the best part so that changes like these can be made by anyone with the time.

Okay I'm not quite done updating it but here are a few improvements I was able to make. The refresh rate is defined by an input, along with if borders should be drawn at the size of the front panel or not. I'm thinking this should probably be a setting in the config file that already exists but for now this is inputs in the Publish.vi. Controls that don't have a specific type defining how they should look default to the Control Class, which will show the control as an image. This means the Show as Image setting is ignored for control types that don't have a specific class handling how they should be displayed. Two examples of this are the cluster with random things in it, and a custom array that shows alternating picture ring images. I believe I have scrollbars working. To do this I had to change the Body HTML, and all controls, decorations, and text to absolute positioning, and then adjust their Left and Top positions slightly because of the drawn border. Now if the web page is too small to show all the items in it (including drawn border, and controls outside the FP) then scrollbars appear. Something I would like to see, and have no clue how to do at the moment, would be to handle controls moving, or being resized. The example that came to mind was if I have an array with 20 large items in it, then I could set the number of rows visible to 20 so all items can be seen, and the scroll bars I mentioned earlier would scroll the page showing all items. But then if I later only have 2 items to show, I'd like to set the number of rows visible to 2, then send the new image with just the two items in it. The problem right now is, the page expects the image to be the size when there are 20 rows, so it stretches the image of 2 to the size of the 20. What I would like is a way to update the HTML file, and then tell the page to refresh the whole thing if something in it changed size or possibly position. Any thoughts on how to do this? Thanks. FPPublisher Hooovahh Edit.zip

So what was needed to make this work? I have an array of controls that I would like to be seen as an image. I found in the ObjectFactory.vi that I needed to add the Array class to the Init state, and then add a state in the Finish state to create the object, where I used the Control class. Then when I ran the VI it asked how I would like to configure that control and I choose as an image. But in the web page all that was seen was an outline of the array control, and nothing inside it. Ideally what would be useful is any control that doesn't have a class made (default case) would be represented as an image rather than having to make special edits for each control type. I had another feature request that I thought would be useful, and that is to have visible scrollbars in the webpage when needed. I tested this by making my VI front panel large, then ran the webpage and no scrollbars were seen. I then made my window small and they never showed up. Is there something simple in the HTML page to enable these?

Who has to deal with DDOS, spammers and abusers? Primarily Michael, forum members to a lesser extent because we are affected too. So I think it should be clear that this decision is in Michael's hands. If I had a vote I'd say to have it open, until something goes wrong, like some script kiddy downloading all CR items continually for days. If that happened once I'd lock it down. But if Michael thinks you should be required to login to perform some actions then that'd be fine with me.

I've certainly worked with other ones, but they mostly all suck for one reason or another. Another issue is all the other cheaper, crappier ones, are so forgettable I don't remember the brand or model. I've heard good things about the BK, but haven't used one programatically before.

Certainly not lots of cases, but even if there are two it is some times easy to update one, and forget about the other. Especially if some other developer is the one maintaining my code.

In this case scripting is your friend. You can have a tool that finds all instances of a type def, that is a constant, and then replace that constant with the updated one. You might have a problem with typed controls that contain that type, that now need to be updated. As for combo box, it isn't terrible, but again if I have a function that really only has three modes I want an enum and then I'll update it later if a 4th mode is added, and every place I have a case structure without that new case being handled, my VI will be broken (assuming no default case which you can do with an enum). With a string you have to have a default case which handles all cases not handled. Also there would be added code to handle if a case is called that doesn't exist, where I know that can't happen with an enum. But again all of this could probably be wrapped in another abstraction layer and these issues could go away with more code.

Yup, there are just some places where rings are so damned convenient. I can have a list of common baud rates for hardware on the UI like 500K, 250K and it translates to a decimal value of 500,000, but then I can have an Other option where the user types in what they want and my code does its best to work with it. Having to translate that back into enums, from enums back to rings, while supporting an "Other" mode, and saving and loading from disk can be a pain. Come to think of it, this would probably be a good place for some OO and classes to handle all of this. But still this is a bit of a band-aid when the IDE could support sparse enums.

While NI takes applications into the project provider, there are some unofficial ways to use it. Of course this comes with no real documentation. It's a bit of a mess really, NI seemingly didn't put in the effort to make this a polished API likely due to the fact that few people would want to do this. Adding items to the menus are a much easier process and in most cases just take putting a VI in the right folder, and then setting it to run when opened. http://digital.ni.com/public.nsf/allkb/2ED4443B186788E18625714000757C03 Oh and while QuickDrop can make the editor a bit easier to use with scripting functions, there are only so may keys you can use, and then there is the fact that you need two shortcut keys to invoke your function. A better idea might be to put something in the tools menu, then invoke it through a single shortcut command. This can't happen today, but there is already an idea exchange item for it.

Based on how seldom the toolbar has changed over the years, I suspect it is not a plugin based design. The buttons you see are the same buttons that have been there (with a few exceptions like cleanup) since 2004 or earlier. If it changes that little, I doubt NI made it a plugin design. You can put things in various menu bar items, like Tools, and File which can be useful for calling VIs to perform actions on the open VI. And there is the Project Provider Framework, which has the ability to add items to the project toolbar, but not many people do this because it can be a pain to work with, and is somewhat incomplete. That being said this is probably a good idea for the Idea Exchange.

Yeah I don't like how the features of one I want in the other. It some times means writing code that will go from a ring, to an enum. Here is an idea exchange for making enums have non-sequential values. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-sparse-enums-to-LabVIEW/idi-p/925224 Even so I would expect a strict-type def ring to update a constant, but I guess it doesn't.

I've had good luck with the Genesys Lambda TDK supplies. Rack mountable, modern, and a few features I don't see in a lot of supplies. We've had cases where we would need 3 power supplies in one test rack. Maybe a low current high voltage, high current high voltage, and low current low voltage. Or there might be designs where we have one power supply for each nest location so each UUT gets a separate supply. Normally for serial devices this would mean one RS-232, or RS-485 for each supply. Or you can go with the more expensive GPIB. But these supplies can be daisy changed and addressed. So one RS-232 port out of a computer can control I think up to 16 supplies. Another neat feature is the quick ability to change out of remote mode which some might see as a hazard but I think it can be disabled. There might be times I would command the supply to something using the software, and then I would want to manually override it with the controls on the front. All you have to do is press the remote/local button and then the controls on the front are enabled. After I command a new output using my software it turns back into remote mode. As for drivers, every Genesys I've used work with the same drivers found here. Pretty clean, and much better than some I've seen in the driver network. It's what I recommend for new systems, and using the same drivers for a large range of capabilities makes swapping them out easy. Of course a IVI compatible supply can say the same thing.

Yup another vote for MGI. I believe it does read/write the whole file so some trickery might be needed to make it as modular as the OpenG calls. The reason it is slow is because the OpenG functions call the NI INI functions under the hood. And each line in the text file is a call to the NI function, where the MGI write their own INI parsing code, and reading and writing is just one call to a file I/O primitive. Basically if you have a file that is 5KB in size or so either will work fine, but if you get clusters of arrays of clusters and your output file is larger than that, then you'll end up with slow downs. Another option I used in the past was to flatten large structures into binary blobs. This would mean the OpenG INI writing would only need one call because that binary section would be just one line. Of course the down side is that data type won't be human readable in the file, and changes to the data type will cause errors, where the INI parsing does a decent job at preserving it.

Topic split. Next time feel free to make a new thread when you have a question which isn't related to the original thread.

Have you used a version of LabVIEW from the past 6 years? It seems your preferred version is 2009. I've used every major version of LabVIEW between 2009 and 2015 on at least one real project, and stability has been the focus more or less for the last few years. It is far from perfect but I think the statement about stability and performance being a focus is true. I think we can agree that the focus certainly hasn't been groundbreaking new features.

Sweet, thanks for sharing.

Yeah I can't remember why I didn't make that method a type def. Regular expression is a good improvement too. Just in most of my situations I have controls named a specific way if I want their references. Like maybe I'll have all controls starting with "Initialize:" for controls that should be shown during an initializing state. Then I can find all controls that start with "Initialize:" and disable them all at once.

I think I saw this error when I was on LAVA from chrome on my phone.

This is probably because a copy of the XNode is in memory. Just like an XControl you can't edit an XNode while it is in memory in another instance. At least I think that is what is going on here. They shouldn't be locked. Neat addition feel free to post your contribution if you get anything working. Super cool BTW.

The truth is I call this place home more than any other, and I suspect I'm not alone. I still learn the most here, I still contribute the most here, and some of the best frank conversations take place here (as shown by this thread) Based on your line of questioning I'd suspect you are having a change of career, or internal struggle. In either case these are going to be very personal feelings, and somewhat unique to your situation. I'm happy, others are happy, if you aren't happy I can see why you might want to change something.

I'm sorry you've been somewhat disconnected from the community. Obviously I'm a bit biased but LAVA and the NI communities serve very different groups. If I was forced to migrate to an NI community I think you'd be harder pressed to find a group like this with as good of code repository, discussion, and light heartedness. LabVIEW in my career is hardly obscure. Job postings I applied for a year ago are still looking for experts. Restructure isn't a terrible idea and a LAVA face lift is a good start.

Well you shouldn't need a license to edit them, they are just XML and can be read in a text editor. I haven't yet figured out how to link to a specific post in this new format, but the New XNode Editor 2012.zip I posted here should allow you to look at all the abilities in an XNode and do some basic editing like add other abilities. EDIT: Oh I figured it out, this is the actual post.

I can't say for certain but I'd say based on what I know, the XNode would need to support this feature. An XNode doesn't inherit from a property node in this case, so methods that cause a property node to be updated, won't work on an XNode, even if its appearance is that of a property node.

"This" is a term I've heard NI use to refer to these types of references. If a reference is a This reference (like the This VI, or This Application, or This Control) then yes closing it is a no-op. The reference simply cannot be closed because it is being used. One way to know if your reference is a This or not, is to cast it to a U32 and look at the refnum. If the number changes with each run of your VI then it is a new reference and should be closed. If it is the same then there isn't a need to close it. I've also done a test where I run the VI using the run continuous and see if the memory in task manager increases. If it doesn't then what ever references I'm opening and is enough for a stable system.