Jon Sweeney

QUOTE

If a window is maximized it should not be movable by dragging the title bar.

QUOTE ( @ Mar 21 2008, 12:55 PM)

That's what I thought too, until No.1 posted his problem. I converted his .bmp file to LV code (using v8.2, PC) and found that as long as the Resizable property is set to False, the maximized window can be moved**. It doesn't really even appear to be maximized because the thin border is still displayed all around, and when the program is stopped, the title bar symbol (whatever it is called) indicates not-maximized. This appears to be more of a "FP.SizeToScreen" mode as in v6.

When Resizable is set to True, maximize works as expected**.

**except sometimes the first time it is run after changing Resizeable from T to F or from F to T!

QUOTE (No.1 @ Mar 19 2008, 08:25 PM)

Hello, everyone,

I want my user interface window to be maximum, and also want to disable the restore button when I open the vi.

I do that as the attached file.http://lavag.org/old_files/post-11095-1205976114.bmp'>Download File:post-11095-1205976114.bmp

but the result is that the window can also be moved by draging the title bar, and also response once when double click the title bar, and then don't response to that any more.

What can I do to realize the function in Labview 7.1? Thank you.

Although it may not be desirable to you, one way is to hide the title bar, either by setting the "Title Bar Visible" property to false, or by unchecking "Window has title bar" in the VI properties.

QUOTE (wiggie @ Mar 17 2008, 12:00 PM)

Hi all,

I created a list and I connected to some subvi, and the problem I have is that I cannot select any item on that list while not in edit mode. When I am in edit mode I can select any item without any problems.

The way I created the list, is simply by adding it and editing the list items and connecting it to the subVi. I made sure that it is marked as "active" under properties. If I provided to little info on my problem, then please let me know.

Here is a screenshot of the list.

Cheers, Paul

I may be missing the point of your question, but the following subvi allows the user to select an item from the passed-in "Listbox".

If this is not what you are asking, please elaborate.

QUOTE(lizimunro @ Feb 27 2008, 05:19 PM)

Thanks for the advice. I think it is the serial read that is slowing the loop down as the timer seems to work fine in isolation! It just seems to take about 9 seconds to loop round and so if the time elapsed at the beginning of the loop there is a delay before anything is done about it.

I don't know why that should happen. But you should be able to determine if the reading is taking a long time with a breakpoint before and after the Visa Read. Also put a probe on the Visa Read error-out wire to see if there are any errors (ignore warnings that there may be more chars available).

You should be able to track down the problem source with judicious use of breakpoints and probes.

(As a side note, it seems odd that you are sending the "Radio Selection Code" (F,V, or P) twice, but maybe that is necessary.)

QUOTE(lizimunro @ Feb 26 2008, 06:37 AM)

I have changed te express vi so I am now checking against system time. The time needs to start at the visa write function just before the loop starts. I think I am missing something or have made an error as the timing is still not exact. I still have to wait a few seconds until the check time section is executed and the time reached triggered. I don't seem to have speeded the loop up to execute once every 100ms.

I am relatively new to Labview so may be misunderstanding this completely!

Attached is the updated vi http://lavag.org/old_files/post-10705-1204025858.vi'>Download File:post-10705-1204025858.vi

Your "Time Improving.vi" seems to work fine on my pc (within .2 seconds of the requested time), but I of course don't have the same serial stream as you do.

Have you been watching the error codes to make sure things are working well and not timing out, which would add 10 seconds with the default timeout. Other than that I don't see what could be adding the extra seconds.

QUOTE(tcplomp @ Feb 14 2008, 04:28 AM)

Yes:

http://lavag.org/old_files/monthly_02_2008/post-2399-1202981288.png' target="_blank">

Ton

Thanks a lot. I was wiring the wrong type into the "to more specific class" function.

Say I have a cluster of 4 boolean leds in a cluster on a front panel.

Can I programmatically change the color of the individual booleans (without changing the T/F value).

If so, how?

Thanks.

I recently became unemployed and decided to have some fun with LabVIEW in my spare time, because it has given me much fun in the past. The attached vi is an idea for a multipurpose front panel (pattern). This one is proportioned such that two could be stacked on a screen.

Don't know if there are other front panel patterns (fpp's) available but it seems like a interesting topic to me.

best regards,

Jon

QUOTE(ned @ Oct 3 2007, 07:47 AM)

Here's one way to do it. If you need to change the direction of lines as your code is running, you can clear the existing tasks and create new ones with the lines set as necessary. The VI on the left is "DAQmx Flatten Channel String" from DAQmx - Data Acquisition -> DAQmx Advanced -> DAQmx Utilities; the one on the right is "DAQmx Create Virtual Channel".

Thanks. I'll give that a try.

Jon

Does anyone have a DAQmx example or description for setting DIO lines (eg, NI6225M) at runtime - some lines to outputs and some to inputs.

I have done this with the old Daq "Port Configure" vi but am having trouble determining how to do it with DAQmx.

Thank you.

Jon

These are interesting. How do you turn them off? (See desktop snapshot)

What can not be seen from the snapshot is that

-- all three(!) throbbers are still throbbing even though "throbber.vi" is not running anymore and I have tried to close the "wait dialog with shadow".

-- if i move the Lava screen, the "wait dialog with shadow" front panel and stop button move with it.

-- if i move the block diagram, its throbber moves with it.

I also don't know how the throbber got onto the block diagram. If I delete the block diagram and then open it again, the throbber is still there.

I don't know why or how these things are happening, but it is interesting. And it's not even close to April 1.

QUOTE(jbrohan @ Aug 7 2007, 03:42 AM)

Hi Jon

This looks very useful. Could you kindly post the Block Diagram as a JPEG since I am still on LV 7.0. I'll post it back if you like!

John

John,

I am attaching the image. The only difference between the True and False cases is that "File Path" is connect in the False case.

Also, I have slightly updated the version to allow for a file pattern and start path for the dialog.

Jon

QUOTE(orko @ Aug 6 2007, 11:23 AM)

Thanks! I know I tried to accomplish this some time in the past...this will indeed become useful in future projects.

One note, you forgot to include the "wait ms with err terminals.vi". I'm assuming that it is just what it says it is, a subVI with a wait ms primative inside a sequence with err terminal input/output?

Sorry. It's just a wrapper around wait ms, with error terminals for easier dataflow connection. It's trivial, but I'll include it for completeness.

Thanks.

Jon

I found a way to do what I needed. I am attaching the vi in case it can be of use to anyone else.

It calls Windows functions (Windows>System32>user32.dll) so that the file dialog presented by the Open_Create_Replace File function is viewed in the user-specified mode (eg, details, icons, thumbnails, etc) , instead of always "list"mode.

The calling sequence is the same as for the Open/Create/Replace File function, with the added parameter "View Type", whose value is ring selectable.

Thanks to all who replied.

Jon

Is there a way to open a file dialog in Windows 'details' mode, preferably sorted by date?

It seems that I have done this before (on a different pc) although I may be imagining it.

My windows explorer view default is 'details' mode, but that doesn't seem to matter.

Thank you.

QUOTE(ooth @ Jul 16 2007, 11:01 PM)

Here are some VIs that I use. I cannot find where I got them and I'm sorry to the author for not siting his/her work.

The author's name is included in the context help documentation.

QUOTE(Nullllll @ Jun 26 2007, 02:51 AM)

i have problem in my VI , it is aquring form me password before running the VI , if I run the VI before enter the password it will give me erroe msg??

plz find the attched VI , admit ur help

Nullll,

You should not check the password until you enter something into it. You can do this by using events, or by using a shift register to check when the password has changed (loop until it does). In the copy of your vi that I downloaded, the Password field was disabled, so nothing can be entered when the program is running. You will have to disable it (right click on the control and choose Properties).

I think you should compress your vi to approximately one page, or at least revise it so you only have to scroll in one direction. That would make it easier for you and others to see what is going on. Also take some the bends out of your wires for the same reason. See the LabVIEW help under "style guidelines - checklist" (in 8.0) to get some other good ideas.

Good luck disarming the system.

Jon

QUOTE(JFM @ May 21 2007, 08:12 PM)

The labels must be in front of the plot area to be visible.

oops, sorry, I missed that part.

Jon

Phil,

Nice looking plot.

See if this works for you:

1) move your labels to the back

2) color the black part and the silver frame of your plot transparent

3) color the background of the front panel black

The plot labels now show and don't interfere.

This now looks almost like your original except the other controls are surrounded by black.

You could put the other controls on a decoration or a cluster as a background.http://forums.lavag.org/index.php?act=attach&type=post&id=5915

Or, as an alternative to coloring the front panel black, put the plot on a black decoration and move the labels forward so they are between the decoration and the plot.

Jon

QUOTE(Jim Kring @ Mar 29 2007, 12:56 AM)

I prefer not to use loops, at all -- just use a unowned (floating) feedback node.

James,

Interesting use of the feedback loop. This use doesn't seem to be covered in the LabVIEW documentation at all.

Could you elaborate slightly as to what is going on?

Thank you.

Jon

QUOTE(Neville D @ Mar 23 2007, 01:10 PM)

Another thing you could try is to copy over your labview.ini file from your work PC to the home PC.. (backup before hand). There might be some setting in there that is incorrect or different.

Neville.

Neville,

I switched labview.ini files as you suggested, and the Help appeared quickly.

After comparing the two .ini's and finding no logical reason for the speed discrepancy, I made a copy of the original .ini and tried it. The Help still appeared quickly using this. I then reverted to the original .ini and found that the Help now appears quickly using the original. So the problem is gone, though I'm not sure why. Maybe there was a slight disk problem that was corrected by renaming the .ini file and renaming it back. Not sure, but thanks for the help. The time delay was getting frustrating.

Jon

QUOTE(Neville D @ Mar 23 2007, 01:10 PM)

Another thing you could try is to copy over your labview.ini file from your work PC to the home PC.. (backup before hand). There might be some setting in there that is incorrect or different.

Neville.

Neville,

The palette loading setting had no effect. Will try your other suggestion on Monday. There must be some wierd setting or combination since no-one else seems to have the problem.

Thanks again.

Jon

QUOTE(Neville D @ Mar 22 2007, 02:23 PM)

Try playing around with the Palette Loading options under Tools>Options>Controls/Functions Palettes.

I have mine set to Load palettes in background.

You have to re-start LV after making a change here.

Neville.

Neville,

I'm not sure what the connection between Palette loading and the Help Window is, but I'll give your suggestion a try tomorrow.

Thank you,

Jon

On my work computer (NI PXI-8105, 2GHz, 504 MB, quick internet access), there is always a long delay (~ 70 - 80 secs) before the "LabVIEW Help" window gets populated the first time (and sometimes the second time) the "Search the LabVIEW Help" option is used after LabVIEW startup. I do not have nearly this long of a delay on my home PC, which in all other ways is quite a bit slower. I have LV8.2 on both.

Any ideas of the cause or the cure?

Thank you,

Jon

You're not yet crazy, you didn't forgot and it is not a bug: the behavior has been changed.

The behavior of data range coercion has been changed in LabVIEW (???). Before, the data was coerced on call but that was potential for bugs very difficult to track down and source of numerous service calls to NI. Indeed there is no visual clue on the diagram indicating that the data was coerced on input.

The datarange coercion has been removed for VI calls and you must now coerce the input data using the coerce node on the diagram. There is a message when you convert old VIs to recent LabVIEW versions that tells you that the behavior has changed when data range coercion is used. The data range coercion only occurs for user input.

Wow, I missed that one. I've used the "In Range and Coerce" for other things but never knew it was necessary for input controls that had the DataRange/Coerce set. Must admit though that it makes the diagram more self documenting.

"???" must be before 6.0.1 so I've been in the dark a long time!

Thanks so much for the response.

Jon Sweeney