hooovahh

The current design won't allow vertical separators as it uses an array of picture controls (so each slot is a fixed width). The new version replaced that with a single picture control and lots of messy code to work out which part of the picture needs to be redrawn when the user interacts with it. The messiness is one of the reasons I've never finished it !

That does sound messy.  The other solution I was tossing around in my head, was that each picture could be a separate running VI.  Then you can register for a mouse enter/leave for interaction, and mouse down to know which was clicked.  I did a quick test here which displays images, and each image is a VI.  It's far from perfect, and it actually does resizing (which you wouldn't want to do) but it may give you a new approach.

These are pretty much the reasons I've never released the code 'officially'. Actually the XNode dependency and hence the Scripting tools dependency is pretty easy to strip out and replace with 'static' code. I've sort of intended to do so for ages but somehow other things keep getting in the way. Also, I've a very long term, slow burning, project to replace the whole toolbar with something a bit more flexible that could include other types of control, not just a push button.

This is not a feature request by any means, but if you are thinking about making the tool look more native I would suggest having vertical separators  and a function that allows for resizing the window, which would collapse buttons into a single button when they all can't fit in the display.  See the image of Foxit Reader which collapses the buttons to a >> button which don't fit.

Just a thought.

Okay so I've never really dipped my feet in when it comes to XNodes.  At the moment I'm not looking to make XNodes just understand using them, and really just get others to tell me it's safe.

The ones for discussion are the Array XNodes, and the OpenG Array XNode.  I see the functions this code has and I love the idea of using it.  But I know that there is no support from NI for using XNodes, and I've heard NI say that using them can be quite dangerous (without specifically saying what it could do or how to avoid it).

So I want to pose this question.  Is the Array XNodes in the Code Repository as safe to use as the normal OpenG array functions?  Is there a compelling reason I should not be using XNodes of any kind in an application?  I assume Lava would not certify code that was unstable, and I also see that people are using these functions (over 3000 downloads combined).  So is there nothing to worry about here?  And if these are so great and stable, should I exclusively use these instead of the real OpenG ones?

Here's a toolbar XControl that I developed for one of my applications. It's not really intended for public consumption, so it's almost entirely undocumented and may not all work as exepected or indeed as I intended :-), but there is a minimalist example included in the project.

Amazing, the community again thanks you for your contribution.  The case as you put it is quite undocumented, and needs work, but the concept is there and it works just well.  Also it should be noted to get this to work you need to install the Array XNode library, which also requires the lava_lib_labview_api_scripting_tools package as well.

...However I feel the need to post a topic using XNodes, simply because all I've heard about it is how unsupported it is which makes me nervous.  That being said NI said the same thing about Scripting before it was released and I was using it then too.

EDIT: I made a post expressing my concerns with XNode usage.

So I had a thought.  There are primitives in LabVIEW that aren't exposed, just like there are VIs in the vi.lib that aren't on the palette.  But the thing about vi.lib VIs is I can navigate the the directory and find the VIs on disk.  My question is how does one find primitives not exposed?

I've seen a few instances where someone will post a VI with a primitive I've never seen before and I wonder how people find these, other then finding them on the block diagram of another VI.  A few examples I can think of are the Text to UTF-8/UTF-8 to Text, and Coerce to Type.

Again I understand the reason why these may not be exposed, and I understand the reason why someone would not want to use them.  But I can't help but wonder, where are primitives on disk?  Where is their information stored (VI description and help path for example).  And how can someone find primitives not on the palette?

are you saying to label like this?

Sorry I wasn't more clear.  What I meant I put labels on the side of controls (right or left).  An easy way to see what I mean is to activate quick drop (CTRL + Space) and then use Move Terminal Labels (press CTRL + T) when on the block diagram.

The solution is to architect the VI to only use one event structure.  There is no need to poll in the timeout case of the first event structure, just handle all events the user can perform (like Panel Close  ) in the one event structure and enqueue any states needed to handle the event.  Another side effect of your code is I can't press new game, if a game is still going on.  Again having one event structure handle everything the user can do is the way to go.

Not sure how many pointers you are looking for but here are a few:

The User Logon screen doesn't need the FP.Open or FP.Close (and then won't need the sequence structure) because the VI is configured to open when called, and close when done.

If you want the logon screen to be seen first, why is this not the top level VI and then have it call the UI that the user plays with?

The Logon screen doesn't allow the user to close, and I couldn't find a way to stop it other then the abort button.

The Main screen doesn't allow the user to close.  There is a button but using the normal close is more standard for users unfamiliar with your program.

Get rid of the toolbar for the logon screen.  There are tons of items in there that are just LabVIEW specific.  Only show the toolbar if you have a custom toolbar with items for your program.

Use more states in your QMH.  You have alot of code in the Idle case (with the event structure).  It helps to more easily follow the code if there are multiple states to call so they can be reused.  You could have a state called "Draw UI" which can be called on startup, and every time the user or AI moves.

Your sub VI's have error terminals in locations not seen often.  This isn't bad exactly but error wires are usually on the bottom right and bottom left terminals.  This borders on the line of style guide or preference not sure which.

Control labels being on the right is a preference thing but I think looks nicer.

You have some wires on top of other wires and going in the same direction.  This makes it very difficult to know exactly where a wire is connected without have to triple click it.

I saw some silver controls.  As I've mentioned before I don't have them but it should be consistent. The ones I saw were the error wires by the way.  I also saw some classic error controls.

You are using the Value Signal property node but I don't see where the event is handling the value change.  If you just want to change the value use a local variable.  Or at least use the Value property.  Value Signal indicates you are firing an event for a reason.

Unneeded coercion dots.  A coercion dot isn't necessarily a bad thing, but they can be so avoid them by giving the correct data type or perform an explicit conversion to the right type, knowing the possible consequences.

That being said, you have nice labels, code description, and I like the tab solution for the UI.  You are doing well for someone with a month of LabVIEW experience.

I'm afraid such a list will stay a wet dream. Officially those private properties and methods don't exist and NI people are not supposed to comment on them, but they are the only ones who could really make some educated comments. For me it is just an educated guess.

 

While I think the safety of these two properties is fairly well, as far as rusty nails and other painful accidents are concerned, they were probably made secret since the LabVIEW developers did not want to carve the association between a panel and an OS window in stone. Also as we have seen the move to 64 bit has posed a challenge. Changing the existing property to a different datasize is not really an option as that could lead to very hard to debug bugs, when the truncated value is passed around as a 32 bit entity and eventually interpreted as a handle again, which might be accidentally pointing to an entirely different but still valid object. So in a way not having exposed that property they could easily change it without having to go through 200 documentation change requests at the same time.

I understand why they are private, I was just wondering if in a specific use case if there was any danger in using it.  Say if I'm in a 32-bit Windows environment would there ever be a case where using "OS Window" would cause bad things to happen?  I have very similar questions for a few other private methods too, and was hoping for some unofficial documentation is all.

Hmm, for some reasons it would seem rather strange to support the retrieval of HWND across machines. The HWND really only has any meaning on the system it was created. And if you use the OS Window you are setting yourself up for big troubles once you move to LabVIEW for Windows 64 bit.

 

I suppose you are doing some remote work where you retrieve the handle and pass it back to another function or whatever on the same remote system. The proper way to do such things would be to have the actual handle twiddling all done on the target machine and expose that VI doing this, over the VI server to your other machine(s).

I may not have used the right words but what I meant is "NativeWindow" does not work with an application instance that was opened explicitly.  It is just like the "All VIs in Memory" property.  It will work if you don't wire anything to the reference in terminal.  But if you open a new application instance the "NativeWindow" will not work but "OS Window" will.

This may be better answered in a different thread, but is there a list of private methods/properties that are more stable than others?  What I'm trying to ask is if I use either of these two methods what risk is there?  Knowing these are unsupported functions.  I found the wiki here, but was quite disappointed to find it so empty.  I planned on using a few others like "All Context", and "Is Context Private?" (to get a list of non-private Contexts), and was wondering the risk of these as well.

I know of no XControl that does this.  Why is making it yourself "not the solution"?  And neither is making an XControl?

So one thing that is worth mentioning that I noticed about these undocumented functions is that the "NativeWindow" method does not work for remote application instances, but the deprecated method "OS Window" does.

Sorry to waste anyone's time.  After I posted this I continued my search and I found this private property that works.

http://lavag.org/topic/13803-getting-the-window-handle-for-a-fp-with-no-title-bar/

I'm looking for a way to get the HWND (handler window) of a front panel.  The trick to this is I want to get this handle on a window without the VI running.  The reason for this is I want to bring the VI to open the front panel and bring it to the front of all applications.  The only way I know to do this is using a windows call using the HWND of the window to bring to the front.

In the past I would get the VI's Front Panel Title (using the VI ref and property node) then get the HWND using this title.  Problem is that is the title of the window when it is running.  A possible solution is to attempt to figure out what the title of the window will be in the IDE then get the HWND of that.

So is there any suggestions on how to bring a VI to the front of all windows, without running that VI?  Attached is a test that shows the code working if the VI is running, and doesn't work if it isn't because the title is different.

Bring to Front Test.zip

Thanks alot for that, I had no idea we could embed an EXE like that, neat!

Yeah, I've also tried it with VIs as well (not as useful but I have a use case).  From a users perspective I can see why this is extremely shady.  I can have a VI that has an EXE that is a keylogger, or a virus, or whatever (I didn't just trust me you can MD5 the EXE).  But it is more encapsulated so I don't need to make sure the EXE is in the same directory as the VI, and is included when making a LabVIEW EXE.

@neil I guess you're right about the DLL example.  In either case I don't do it much.

Thank you todd!  

 

Hooovahh, another question for you.  Why did you include a "stop" event case?  Couldn't you have just wired the stop button to the "or" function outside the event structure, but inside the while loop?  Just to be clear, I'm not criticizing, just curious.  Maybe I'm missing something is all haha.

No problem, feel free to question things like this for clarification.

I thought about leaving the Stop in the timeout case, and this is a valid way of handling it for a stop if timeout occurs often (and in this case it does).  I wanted to properly handle the closing of the VI which is why I added the event structure and the "Panel Close?" event.  For consistency I added the "Stop" Value change because it is parallel to the "Panel Close?" in functionality.  Another thing to be aware of is not all applications have a timeout.  Many VIs may only take action if the user performs some action, and in these cases wiring an Or to the Stop terminal is not a good idea, and instead you should have an event that handles the pressing of the stop button.

As a quick example take a look at the VI attached.  It shows three cases, enabled using the Disable Diagram Structure.  It shows polling the stop button, then reading the stop button but without a timeout causes issues, and then no polling but instead using events.  I added the Stop Value change because it is the more correct solution in many cases, but for your VI it didn't really matter.

Stopping Test.vi

Also, my profile does say I use 2012, although it says I started in 2011.

Oops you are right sorry.  

Note Recognizer Hooovahh edit.zip

I definitely don't want to use a functional global (Is that what you mean by VIG?). I don't have a lot of experience with OOP, but so far the couple times I've tried mixing in a functional global have made it hard to maintain in the future. If I want to swap new Actors in, then would they ALL rely on this functional global? Sounds problematic...

Yes, the terminology is slightly different depending on who you ask, but for many cases VIG = Functional Global = LV2 Global.

I didn't know that the Actor Framework was OO based.  Knowing that I also would be careful about using a VIG to maintain settings, but as I said before it could have another layer on top using a sub VI called "Get Settings" which all it does it read a VIG which maybe a little cleaner.

What I'm struggling with is this:

1. Which Actor should store the hardware's current parameters/settings?
   
2. Should there be multiple copies of the hardware's current settings in each Actor?
   
3. How should the parameters be passed around? Should there be an abstract Parameter class?
   
4. If I used an abstract Parameter class, would dynamic dispatch be the best way to handle different UI reactions?
   

I'm afraid of coupling Actors too tightly together. On the other hand, it's not clear to me where the Parameter data should be stored, because it seems like the Controller and UI would need to have access to it. Should it be stored in the Controller and passed up to UI as needed?

 

If anyone has any thoughts/advice, I'd greatly appreciate it.

I am not an expert at the Actor Framework.  I've only used it a few times, so I'll answer the easy ones in my opinion. 

1) The Hardware Actor should have the hardware settings.

2) Is it necessarily for the other Actors to know the settings?  If not then they don't need to know.  If you want the other actors to know I would recommend using a VIG where only the Hardware Actor performs writes, and the other Actors only perform reads.  You could get away with this by using two separate VIs that call the same VIG, one with a constant for write the other for a constant for read.  Then you can find all instances of writing/reading to verify that only the correct Actors are writing to it.  If you have a VIG being written to in multiple places at once there is no way to maintain the correct data (just like a normal global).

Question posted on NI's site. Thought I would list it here in case you don't check NI's forums and you have an answer for my question!

http://forums.ni.com/t5/LabVIEW/Setting-quot-Scale-Objects-While-Resizing-quot-programmatically/td-p/1970005

I am thinking of sharing this API after I get this figured out because it makes collapsing / expanding panes a breeze. Is there is a different easier way to accomplish this?

I have attached what I have so far in an example vi.

I really like the idea of this and am curious about if there is further development/official API?  That being said I found a few issues, some of which I know can't be worked around at the moment.

First if you run the demo and collapse, the play controls, then the one just below it, then restore them but in opposite order, you will have odd behavior where things don't restore properly.  I know this has to do with the interaction with multiple collapses in the same direction (two vertical/two horizontal), and I thought moving the splitter a set distance, instead of to a specific location would fix it but it didn't for some reason.

Secondly is an issue you're already found dealing with the "Scale Objects While Resizing".  It looks like this property is not exposed.  In my opinion this is the deal breaker for this API.  Many times I will have a graph or table fit to the whole pane, and I (as well as my users) have gotten use to the fluid movement of a resize.

I usually stick with the Pane Size events, I believe that those will fire as expected in the subPanel.

Okay so the Pane Size event does fire, but as shown in my example, the Panel Resize does not.

Edit:  Thanks for the cross post.

Okay I swear I saw this somewhere but I can't seem to get it to work.  If I have a subpanel and I load a VI into it, then run the VI and resize the subpanel (causing the VI in it to resize) why does my "Panel Resize" event not fire in that VI?

Attached is a quick test.  Run Child and see the "NewBnds" value change as you resize.  Now run Parent and resize.  Notice that "NewBnds" does not change.

Crosspost

SubPanel Resize Test.zip

I don't know what you're getting at. Are you joking? No offense if you're not.

He's joking (I assume).  We really need to implement the sarcasm font

Yes I've seen this demo, and have played with the XControl too.  A few things I don't like about it (but have never mentioned to the author) is the fact that you don't have control over allowing the user to close a tab or not.  If I'm using this with subpanels, there is a use case where I load a non-reentrant VI into the subpanel and may not want the user to close it.  Also I think it would be nice to be able to have control over what happens when a window is closed.  Should it pop back in or close?