jpdrolet

OK I typed too fast. There is no obscure reason. It works but not always as I expect.

Under silver theme, I colored the label "Seuils d'operation du bulleur" with the system window color. Labels "Version" and "Signature" are colored with system object color.

Under lilac theme (yuck!) the two latter are correct but the first isn't. I guess it's because the dialog tab in the silver theme doesn't the have neither the window color nor the panel/object color.

Is the solution to use a normal tab colored with system object color?

For some obscure reason, I've always thought up to today that system colors on the color palette did adapt to system colors like the dialog objects... So I colored many controls and labels thinking that they would nicely adapt to end user color scheme. I was wrong!

Therefore my wish is that so called system colors be portable and truly adapt to color scheme.

A couple of the LLB subVIs need to be updated.

The one that finds open subVIs was also picking up windows associated with a VI (like the block diagram window and probe windows) resulting in multiple identical entries in the array being returned. It's been fixed so now it just returns one entry per VI.

The one that returns a WinAPI refnum based on a window's name has been updated to account for more variations that are possible for a LabVIEW window name. It's amazing how many of these that there are!

And, for the Windows API to return a refnum, the match with what you see in the title bar has to be exact.

For example, for a VI named XXX.vi the possible LabVIEW window names include:

XXX.vi

XXX.vi Front Panel

XXX.vi *

XXX.vi Front Panel *

and if it has a window title of ABC too, then these variations get added:

ABC

ABC [XXX.vi]

ABC [XXX.vi] *

ABC [XXX.vi] Front Panel

ABC [XXX.vi] Front Panel *

The "Get Window RefNum.vi" in the "Windows API Function Utilities" referred to earlier in this thread assumes you are passing it the actual title bar text. And since, to the best of my knowledge, LabVIEW itself provides no means of providing what it actually places in the window title bar, you have to try all the various permutations. :headbang:

And you forgot the option "Show revision number in title bar" that adds "rev. nnn" to the title bar...

Ctrl-A to select all the text.

See the attached VI.

In LabVIEW you create a cluster with your data as {long,string,float[]}. This can't be flatten directly since a flattened LabVIEW string is headed with its length (which is fixed in your data format). The string is first converted to a cluster of 40 bytes. The same would be done on float data if it were of fixed size (array to cluster). However, the structure used to transmit array (long Nvalues, float data) is the same as LabVIEW flattens arrays so no conversion is required.

To read it is a little more involved since you have to read the float data length and after read the data.

Download File:post-447-1127195155.vi

So, the moral of the story is... Provide a test harness to test all VI's before release.

A much simpler preventative measure would be to position the inputs and outputs at the same alignment. This way you don't have to think too much about wiring mistakes. Having them swapped like that is asking for problems.

Another thing in this example is the coercion dots. Correct connection removes coercion. The coercion in this case would raise a flag to the programmer. This is why I change the colour of my coercion dots to bright red instead of the dull grey.

Strict Typedef is also a good idea even if the data is simple integer. The coercion then does appear when different typedef are connected. For identifiers, uncoercible types are even better, like the datalog refnum used in GOOP implementations.

Came across this submitted vi, but did not open or look into further.

This code is by Dan Andersen

http://sine.ni.com/apps/we/niepd_web_displ...rank=&p_answer=

It is just a VI to start DIRECTCD.EXE with System Exec.

You probably couldn't find it, due to NI's spelling mistake (LVRoot\project\_NewProbeWizard.llb\Get Contorl From Type Descriptor.vi).  See this thread for more info.

6110[/snapback]

That's it. Thanks, Jim.

And has this old issue of creating a control typedef (instead of creating on a standard VI FP) been resolved?

I want to automate the creation of clusters from C structures statements. I can create the TD from the C structure but I need to create a control or typedef from this TD. I seem to recall a VI that just do that in the LabVIEW distribution but can't locate it. Can someone refresh my memory?

On the other end of the spectrum (pun intended) I use system colors and dialog controls. At least they adapt to the color scheme of the OS...

Yeah but for your specific example (testing for NaN) the native Conditional Double Probre doesn't work since (anything == NaN) will always return False, even (NaN == NaN). You have to wire your own custom probe to test for NaN using Not A Numbe/Path/Refnum. OK I'm picky.

This can't be done. The resize object only works for a single object. Grouping them doesn't work... sorry.

Well, the instructions mentioned give you some capabilities with zero programming. Of course if you tap into the panel resize event and want to do some programming then you can do whatever you want. Anything is possible in LabVIEW once you use this event.

5992[/snapback]

The panel resize event is tricky tu use. Tens or hundreds of events are fired while the user resizes the panel. If you make something that forces the panel to redraw, it is funny to see the panel keeping redrawing well after the user has left the mouse until all events are serviced. You have to catch when the mouse button up but since the handle to resize the panel is "outside" the panel, it does not fire a mouse button event in the event structure. You have to use the mouse device functions to detect the mouse button up.

Indeed, this feature is a blessing...

Interesting to note, thank you. I also came across another interesting deviance. The  Formula Parsing requires ^ for exponent while the Formula Node requires **.

I was trying to be able to read in formulas from files into the formula nodes but it doesn't seem to have a way. Does anyone know of one, or do I have to continue using Eval?

5953[/snapback]

Formula nodes can only be modified at edit time. Use Eval.

And the original post also holds for expression nodes.

That must be very old but anyway...

For example, the result of arithmetic operations on uInt8 are coerced to 0-255.

5-10 gives 0

250+10 gives 255

Edit: This is alos true for expression nodes

That is a quite different implementation than the arithmetic nodes, where the results are modulo 255.

5-10 gives 251

250+10 gives 4

At last the magic revealed! (you didn't reply when I PMed you about this... )

Thanks for the extensive animation.

:star::star: (sorry, wrong forum...)

But how is the lady cut in half?

In case structures, you usually have to enter all included values, if the case structure handles integers. For me, this would be a strange feature, if strings are handled differently. So I think this is a bug.

5893[/snapback]

It behaves differently for strings and numbers and I think this is the intended behavior.

The difference comes from the fact that strings are variable length objects. If the case for string range were inclusive, the range "a".."z" would match for all strings of any length beginning with "a" to "y" plus the lenght 1 string "z". To match all strings beginning with "a" to "z" you would need to set as the upper range the lexically largest string begining with "z" that is "z

I'm not sure if this is a bug.  It might just be a feature.  I recall a thread on info-labview on this a few years ago.  I think that when you are using string ranges, the upper limit is non-inclusive.

5846[/snapback]

It is a bug. The VI should be broken for "no case for some selector values".

Could just as easily been titled "How to eliminate vendors based on drivers.

5824[/snapback]

What a nice if...elseif structure...

I bet it has been coded by a C programmer that didn't know about the switch statement...

I am a physicist.

.

.

.

.

.

.

I'm glad you said "Almost"

There is no data dependency between iterations so you seem to keep ALL data in memory when you don't need to. You should write data on file at each iteration of the main for loop and not build arrays of data to be written on file later.

Hello

All we know shortcut Ctrl+A for align object to left edges.

Are there any other shortcuts for align right, center or - little bit important - distribute let's say vertical gap?

Best regards

Mikrobi

Zbigniew St. Sobk

Unfortunately there is no event condition when the index value is changed.

Use a separate control to feed IndexValue properties of both arrays and then you can use value change event.

Take the insanity test. I am insane which I have known for a long time now.  

http://www.tekzoned.com/instest/

5445[/snapback]

Actually I think that it is listening that clip that makes you insane within 60 seconds...

Here is a solution.  This will find its way into the OpenG file library soon...

5372[/snapback]

Does the Application Method Get VI Version exist in 6.1?

The Reinitialize All to Default won't work because it won't clear the uninitialized shift registers.  Revert VI works except it erases unsaved changes.  Is there any reason then that you can't just save the VI changes before reverting?

5317[/snapback]

The only reason is to check if changes work before saving... But yes it could be done by saving before and one could make a tool Save VIs and then Revert VIs. I checked and Revert VI does revert the VI even when the VI is unmodified (and it resets default values). However I think it takes much more time to reload a whole hierarchy from disk than simply clear USRs and reset default values.

And I want this integrated into LabVIEW...

Another way to reset USR is to force recompilation (Ctrl-Shift-Run Arrow) but then all VIs are flagged as modified.