shoneill

Are you therefore postulating that crelf doesn't troll at all?  We must explore all avenues.

OMG.

I just read through this thread in its entirety.  My opinions on many LAVA members has been irrevocably changed.  I almost wish I had never read the entire thread.

The thing which popped into my head most while reading this thread was the following link.  http://en.wikipedia.org/wiki/List_of_fallacies

Shane.

You would need to cast to an XControl reference, get the "facade" VI reference and parse from there.  I have to admit I don't know how to do this, but I have never tried either.

One major thing is simply to have a convention and write it down.  I'm not aware of one convention to rule them all so to speak.

I tend to name accessors Set and Get instead of Read and Write because Set and Get have the same Nr. of Characters.  When listed in detailed view, they seem easier to read for me.

Just to follow up a little.

I've had success with adding the entry

RTCloseVIsOnDocMod=True

to the ni-rt.ini on the root directory of the RT system exhibiting the problem.  This seems to get around the problem of the RT and host getting confused because of changed VIs not being deployed properly.  Your mileage may vary.

Yes, because that isn't necessarily a recursive call at run time.

Well it IS recursive (guaranteed) when the input terminal for the top-level DD call is directly connected to the DD sub-VI (as in the pic above).  Or am I overseeing something?

We already have type propagation checks for other LVOOP aspects (whether output wire has a direct connection to input wire for type retainment).  Should this not be another check?  I agree that the presence of the VI in itself does not automatically mean it's reentrant but having the input terminal wired directly to the VI does.

I think this could be an option to break the run button if the DD Vi is under these circumstances NOT set to be reentrant.

Otherwise I actually like LV leaving us to decide whether something is safe or not!

Shane.

This might also go some way to explaining why DD calls are actually very expensive compared to standard VI calls.....?

I see it on occasion but I can't tell you for the life of me when exactly it occurs except that with VI Server References coupled with case structures and shift registers. Sometimes the rules for deciding which actual data type the wire is seem to be a bit backwards (It retains old types even though the only definitive source has changed).

Oh, LVOOP and Real-Time.

I seem to be having problems with this also.  I get lots of warnings when exiting LV that are related to a certain class (with only static inlined VIs).  I've also been seeing completely different code running ont he RT than in the IDE.  That makes debugging kind of hard.  I've had VIs running on the RT but not marked as reserved on the host and vise versa.

Apparently adding the line "RTCloseVIsOnDocMod = True" to the rt.ini in the root directory of your RT system can help this problem.  It certainly helped me.  Clearing my source code cache made no effect fo rmy problem.

I'm not 100% sure it's related to inlining but here goes:

recently (Actually it seems to be happening a lot since we installed the "November 2012" patch for RT (which is supposed to fix glitch issues with FIFOs)) we started seeing what can only be described as "weird sh1t" happening with our code.

When debugging RT code in the IDE and running the top-level VI from the IDE (plus automatic deploy and so on) we would see VIs which are running on the RT not being reserved (or marked as executing) when viewed on the host.  With time I realised this was simply a mismatch between the deployed code and the IDE source code which led to all kinds of performance debugging nightmares.  Debugging nightmares in general in fact.  Setting probes where you KNOW it has been executed but not showing any values (listed as "not executed") is perhaps the most harmless version of what I was seeing.  Hard crashes of the entire LV system was less harmless.

I got some keys from NI which should have fixed the problem but actually led to all deploys failing and the VIs complaining when trying this were nearly all inlined - hence my irritated glance in that direction.  I deleted the keys but am left with a system where I'm never quite sure which version of my software is actually running on the RT.  I've spent days trying to debug something and tearing my hair out only to have the software (unchanged nominally) working fine when I re-connect the next day.  My sanity is intact though, that was actually in doubt for some time.  Another work colleague has started seeing the exact same behaviour.

I got more keys to fix the behaviour but I haven't tried them all out yet.

Shane

Ooh, Warnings with inlining.  I think I should write a song about it.

It's driving me nuts.  Also problems with deployed code on a  RT not matching the code in the IDE when editing and runn ing code from the IDE is a nightmare....

Roll on LV 2020.  Maybe we'll have a really stable version by then.

Stick a decent SDD in your old i5 and you should be fine.

Programming LV on a SSD is amazing due to the multitude of small file accesses.

Shane.

Perhaps the lack of a UI event structure to handle the UI events?

I don't really know otherwise.... I don't know how much RT and XP Embedded are similar.  I only have experience with RT (And even there, I don't have much)

I can't run your code without hardware.....

I would say that almost all of the time it's POSSIBLE to do what I do without using multiple event structures in a single VI.  But if the workaround (automatic upgrade path) is to simply plop each extra structure in a sub-VI (and perhaps inline it) then what advantage is the change actually going to bring?  It seems like an optimisation which could cause more problems than it brings but IF it brings some magical properties, then I'd be all for discussing it.  I'm the last person who thinks that backward compatibility needs to be maintained at all costs.  I feel there are many big changes which could benefit LV but I don't have the insight into the inner workings to guesstimate whether this would be worth it or not.

Not in LV 2012 they're not.

The folder  is there, lots of other VIs are there but your "Set Texture" Poly and the "Rotate Z axis.vi" are not included.

I do actually USE the 3D Picture control so I certainly have the functionality installed in LV 2012.  Can't you simply save the full hierarchy?

Sorry, still can't help.  Several sub-VIs are missing.

Ooh this sounds familiar.

I had some WEIRD performance issues a few weeks back with the divide primitive taking different amounts of time depending on which values it was dividing, and I mean MEASURABLE differences.

Closed the project, re-opened and the issue was completely gone (hopefully) never to be seen again.

It seemed at the time like the math libraries had started going a bit wonky.

As with all problems of this ethereal type (you look at them properly and they disappear) you end up questioning your sanity and have no change of filing a bug report because noone will be able to reproduce it.

Shane.

I would check it but have only LV 2012....

You have LV 2012 in your signature, but your file is LV 2013.....

Yeah, speak up AQ....

Limiting to a single event structure would break so much of my code I'd be seriously tempted to start learning C++ again.......

I'm not exaggerating.

When I launch my factory, the code does the following:

- Obtains a new one element size queue with a LV Object constant as element data type

- Loads the child using the factory

- Enqueues the new child in the queue using the function 'Lossy queue element'.

 

Obviously, at that moment I had my child in memory, but I discovered that once I released the queue, the child vanished as well from the LV hierarchy, allowing me to load a new child in case I needed, using the factory pattern again. You can find the code attached with the post.

That's really cool, I did not know that removing a loaded class was possible.... Must remember this.

@mje

Virtual machine - VPN - Remote desktop.

That's exactly what I've been doing for a while due to this extremely annoying behavior.  It's all good if Darren can show how fast he  can program with quickdrop and all but out here in the real world (home office days or remote debugging) all that is worth very little.  The lag over this connection (not to mention the less than 100% fidelity of mouse integration over Remote desktop) makes programming really chore.

I have started compositing my classes.  You could include a "Protection" class in your different file formats which offloads the protection functionality into a seperate class.  That was inheritance is no longer an issue.  You then have a file class with a bunch of sub-classes which you can access one by one and query whether they're implemented or not.

I'm currently slogging through both season 6 of mad men (with the wife) and season 3 of Boardwalk empire.

It took me a while to get "into" boardwalk empire but once you get to know the characters just a little it became quite compelling to me.  A lot of good actors in there and fantastic production quality.