clbst47

Here's a fun one.

Can anyone tell me why the attached VI generates an error (my favorite error code, too - error #1 :headbang: ) when a user releases control of it in a web browser? This is a very straightforward example, so I'm hoping I'm missing something obvious or that it's machine-dependent. Otherwise the web server's going to be pretty useless for me in my application...

How to set up this problem:

1) Start labview and make sure the web browser is enabled ("Tools" menu)

2) Place the "WebServerError.html" file into the "...Labview x.x\www" directory

3) Run "WebServerError.vi"

4) Open your browser and go to http://[your_machine's_IP]/WebServerError.html

5) Right-click on the panel in the web browser and select "Release Control of VI"

This generates error #1 on my machine (running WinXP and LV8.2).

I'd like to know if others can generate the same problem. Just as a disclaimer: yes, I know there are other ways to write this code , but this strategy is representative of one used in a much larger, much more flexible application.

I appreciate any help the experts might have!

Birthday cake on the "About LabVIEW..." page.

Nice.

If anyone knows about the timing of an 8.1 release, please give us a hint. I have found LV 8.0 to be extremely buggy, and am in the midst of tweaking/hacking all my projects to get around the numerous bugs. Perhaps I won't have to fix quite so much after 8.1 comes out. What's the projected timetable?

OK, so when I change the location of the "LabVIEW Data" folder using the development environment options, the location changes sure enough - until I run an executable. Then the "LabVIEW Data" folder again gets created in the "My Documents" folder. It's almost as if the run-time engine has a data path of its own...

Two questions:

1) Anyone else able to replicate this on their machines or under a different version of LV or the RTE (I'm using LV 8)?

2) Anyone know if there's a separate .ini for the run-time engine (or some other way to keep an executable from creating this folder in My Documents)?

As usually happens when I post something, the answer comes to me shortly after clicking the "Post New Topic" button...

I just added the "DefaultDataFileLocation=..." tag to the .ini file of the built executable, and that did the trick. Kind of a pain to have to do it for every built app, but...

I heard someone mention October at NIWeek.

5772[/snapback]

I heard October 3 at NI Week.

Well, as usually happens once you make a post, I figured it out. First of all, just what the correct answer should be varies from programming language to programming language (hence my confusion), and there is much debate on the topic among mathematicians (http://mathforum.org/library/drmath/view/52343.html). However, the key here is the "floor" function (at the output of the Q & R function), which helps to explain what LabVIEW behaves as it does.

OK, I'm willing to admit extreme ignorance as to how one of the most basic functions in the programming world is supposed to work, but I'm a little confused at the output of the "Quotient & Remainder" function in LabVIEW 7.1.1.

My assumption is that this function should compute and return the quotient and remainder of its two inputs, regardless of their sign. Therefore if the inputs are 100 and 90, I would expect a quotient of 1 and a remainder of 10. Similarly, if the inputs were -100 and 90, I would expect a quotient of -1 and a remainder of -10. However, for this latter case, this is not what you get (see attachment).

...So what am I missing?

I have an application where I'm displaying multiple plots on a waveform graph. I would like to be able to draw a visible box (using the mouse) around a subset of the data, and then return the plot points thus selected. I first thought cursors (having them snap to the current mouse position on a mouse down event) - but there's no way to "draw" a box on a graph using cursors as far as I can tell. Plan B might be to use the box zoom tool, allowing the user to select a portion of the graph, after zooming to get the max/min of the graph, then undo the zoom (all the while deferring panel updates so the user can't see what's going on), but this seems like a hassle and it doesn't appear that deferring panel updates holds for zooming (the graph is updated in spite of the setting). Can anyone think of a better way?

Hi Clbst47:

Yes, you can do it.  Application control>Menu>Current Vi's Menubar will allow you to put a reference to the current vi's menubar on the block diagram. 

On the panel of your Sub-vi, you can insert a control that you can wire up to this reference (Controls>Refnums>Menubar Refnum.)

Then you can put whatever menu control stuff you want inside the sub-vi.    Can reduce a bunch of clutter on the Main Vi's diagram.  Can also save a lot of work by having the sub-vi used by many callers needing similar menu service.  I've used it to great benefit for both. 

Easiest shortcut is to start with the menu stuff on the main vi, select what you want to put in the sub-vi (not including the Refnum constant) and then use create sub-vi.

Be careful about trying to do two things at once with a menu-- most cases were this is a bad idea, with unpredictable results.  So be sure to always daisy-chain menubar out from one menu operation to the in of the next operation.  This might mean that you need a menubar out indicator on your sub-vi. (I think you might be able to save the menubar as Global, but that's a really dangerous idea.    Even those of us that like Globals for some  purposes cringe at this & I hate to think how the no-globals-ever-no-matter-why guys would feel about it.

Good luck, hope this helps.

3943[/snapback]

Thanks for the reply - I would really like to be able to do this w/out passing in a menu refnum. Is this possible? I simply can't believe that the menubar is not an exposed property of a VI somewhere!

Thanks for the code examples guys, it will help me in other areas, however what I really wanted was to create a (strict) property node to an existing control. This should not be wired to a reference but implicit. I'm afraid this is not possible with what we know, right?

730[/snapback]

Michael:

Did you ever figure this out? I would really like to be able to get a strict property node to a control in a VI from within a subVI *without* creating and passing in the control references from the top-level VI...

...anybody know if this is possible? I can find the "Run-time menu path" of any VI using VI server, but can't seem to get the refnum so I can manipulate a VI's menu from a subVI, for example.

I gotta imagine this is possible, and I'm just not looking in the right place...

Interestingly enough each page on a tab is similar to it's own front panel.

If you look at the properties for a tab control you'll see a property called Pages.

It is an array of references to the individual pages.

From there you can get to a property called CtlsOnPage.

That is how you dig down into the tab control.

True - but I then have to iterate through all the refnums, looking for the one I want (while closing all the rest). This makes a block diagram where you're doing a lot of control/indicator manipulation pretty messy pretty fast. It would be really cool if I could access a specific control or indicator in one step, and I was hoping I might be able to with this primitive (it already gets me halfway there, since I don't need to iterate through all the refnums (and close all the unneeded ones) returned by the "Controls[]" property of the "Panel" object).

...so any idea what "name/order" means? Obviously, you can put a control/indicator name in there and get the reference - what's with the "order"?? I thought maybe you could put in a special syntax to specify the "order" of the control you're after, like "MyCluster/MyBoolean" or "MyCluster:MyNumeric" or something...

Thanks for your quick response on this, BTW. It's nice to talk to some real LabVIEW experts for a change instead on NI tech support.

Chris

Primitives

New VI Object: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterConnector.vi

One of the most interesting primitive, open a whole new realm of possibilities

Open VI Object Reference: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterCopy.vi

568[/snapback]

Jim - this topic is fascinating! I have a question - I'm trying to use the "Open VI Object Reference" primitive and can successfully get the references to "top-level" controls on another VI's front panel. If I wanted to access the controls within a cluster or on a tab control, though - how would I go about doing that? I am guessing there's some syntax for the "name/order" input, but...