Wolfram

What I mean is the difference in behaviour between LabVIEW 2010 and 2011. In 2011, the VI hangs. But there is also another solution: If you replace the tunnel with a shift register, you can execute the Unregister For Events.

BugRegShiftReg.vi

In LabVIEW 2010 SP1 is ok. In LabVIEW 2011f2 NOT ok.

Open and run the attached VI first in LV2010SP1, then try in LV 2011f2.

Greetings

Wolfram

BugReg.vi

It's no longer annoying in LV2010. Same behaviour in BD like in FP.

Wolfram

Thanks for your hint. I agree with " Ideally, the primitive should have broken the wire...".

Hi all,

here is another issue I faced caused by "Not A Number/Path/Refnum" Function in LabVIEW 2010. But I'm not sure, if this is a bug.

Wolfram

LV10BugRendezvous.vi

Hi folks,

attached I have a VI that produces a memory leak. It works ("misworks") in LabVIEW 8.6 and 8.5/8.5.1 but not in LabVIEW 8.2. The attached VI is saved in LabVIEW 8.5.

Wolfram

I prefer not to process any callback in the callback VI itself. What I do is to fire events of any callback into a single queue, by which queue element is a cluster of an enum [state or callback name] and a variant [hold the data]. An existing centralized queue state machine will than process all events of all callbacks. Make the enum "state" as type def for easy and fast adding of new states.

Wolfram

I've encountered the following bug: See attachment

It is one of the bad and strange ones.

Wolfram

Edit:

I've replaced the attachment. There was a race condition in the

previous demonstration VIs.

Wolfram

Take this control. The trick is to put the text over the icon.

Wolfram

ZITAT(tcplomp @ Jul 4 2007, 08:13 AM)

Somehow I expecte the following code to set the VI to be the active window:

http://forums.lavag.org/index.php?act=attach&type=post&id=6302

But the Frontpanel is not the active window.

I set my Front panel to be floating:

http://forums.lavag.org/index.php?act=attach&type=post&id=6303

Does anyone know a solution?

This is all in LV 8.2.1, in LV 8.0.1 it works as expected

Ton

See here: forums.lavag.org/index.php?showtopic=8523&pid=32105&st=0&

This might help.

Wolfram

There is a "BringToFront" method that might be helpful. The "BringToFront" method can be found in the application class.

Otherwise you have to use some Windows API functions.

Wolfram

ZITAT(BrokenArrow @ Jun 19 2007, 03:03 PM)

Parallel loops...

Loop 1 writes to Howdy.txt file every 2 minutes to 30 minutes.

Loop 2 opens up Howdy.txt every 1000mS and looks at it - to see if it's been written to. This happens all the time, 24/7.

With this scenario, it appears there's a small chance the file can be open at the same time in two places. Is this common? Can it cause problems?

The VI's are Write Characters To Fle and Read Characters From File.

You can do this when you open the file in loop 2 only as "read only". Then it should work.

Wolfram

ZITAT(engineer123 @ Jun 20 2007, 08:43 AM)

Hi,

I have a problem in calculating the time difference between 2 events.

Can any one see the attached VI because the difference is not correct.

Thanks in advance.

The calculated time difference seem to be correct. So I don't know where the problem is.

Wolfram

Look at this registry key (just read it out):

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ComputerName

There is a command called "getmac" to get the MAC address.

See in help of Windows XP.

If somebody wants to download "Lapview" .

http://www.fullreleases.com/NewMembers/ful...?search=Lapview

Generating objects programmatically is a feature that is called scripting. This is a hidden feature

that can be enabled by a special LabVIEW.ini entry (reserved only for NI).

In LabVIEW 7.1.1 this feature can be made visible by adding the keyword "SuperPrivateScriptingFeatureVisible=True" in the LabVIEW.ini.

Have a look into the "rusty nails" -> "scripting" topic in this forum.

Unfortunately this keyword does not work any more. NI has changed this in LabVIEW 8.0

Wolfram

ZITAT(jlokanis @ May 25 2007, 01:17 AM)

Does anyone know of any advantage or disadvantage to any of these methods?

There is one key feature:

If you want to hold a VI to itsself for hidden top level execution, the only way is to

use the "Open VI Reference" primitive. Otherwise, the execution stops immediately,

if you close the front panel.

Wolfram

My opinion:

This is an additional way for NI to make money. Last year, we were force by NI to make

at least the CLD certification. Otherwise we would loose the status to be a NI selected

alliance partner. So we made it.

ZITAT(Aristos Queue @ May 9 2007, 04:06 PM)

Bug confirmed. I'm investigating. I'll try to get back to you before the end of the week.

CAR 49882DJ1

Hi Aristos Queue,

have you investigated this issue. I'm interested how it is going on.

Wolfram

I found out how to get this error dialog. See attached VI-Lib.

Hope this will help someone to get rid of this error dialog when

exiting LabVIEW or the application you made.

Wolfram

This bug on tab controls is a really really old one (since LabVIEW 3.0). The problem is that the front panel interface does not show the corresponding tab page, if you change the value of the tab control in block diagram code programmatically. I found out the following solution. Write to both a local variable of the tab and a tab property "value". This works in most cases. I suppose that the property "value" forces the panel to update the page finally.

I hope this helps.

Wolfram

Hello Michael,

I've translated one file for you (see attachement). If I have more time, I will do the rest.

But this to do could take a while...

Regards

Wolfram

Hey Guys,

I am still wondering what causes can stop a program which front panel state is set to hidden. Because every night around twelve it stops, but keeps running if the front panel is open. Guess I have to ask my system manager what is happening at night.

Eaolson, yes you

This is really weird.... Can I trust my LabVIEW to compute correctly after bugs like this and the constant loop bug?

Strange thing like the "For Loop" bug in 7.1.

I guess, we can expect LV 8.2.1

I also found out the same behaviour in LV 7.1.1 and 8.0.1

Wolfram