From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Has gotten me thinking about how to handle preserving a memory location for external data updates. @009 has much better memory management- couldn't a Preserve Memory primitive be written? For obvious reasons a counterpart Deallocate would need to be required for each "Preserve" call
Yes <shift-2> is where its @. I tend to get a bit confused with the shift and caps-lock keys (very embaressing) but blame it on LabVIEW. Also- I'm a tabber- (the tool selector has some disadvantages) and a BAD typist- I put lots of "``" comments in my code when I miss the TAB.
@Intaris- The post linked does have code with a dll call. Pass in a buffer and it continues to update that memory location. Some surprising effects occur! What exactly can be done to make this type of dll fn safe in LabVIEW? This idea is simply to prevent LabVIEW's dynamic memory manager from re-assigning a block of memory that is updated from outside LabVIEW
@009. 2009. Of course that makes sense now. It just didn't cross my mind when I read it. And there have been several recent posts on the forums lately where people have been referring to programs I've never heard of before (someone was recently asking about "vbx spreadsheet"). I just thought this was another one of those arcane programs.
For reference, this idea seems to be related to this message thread.
Somehow my brain had filtered out the Hyperlink. I had been reading the thread on the support forum so I kind of guessed that was the kind of thing being referenced (no pun intended).
Interesting idea. Maybe someone from NI could tell us something which prevents a memory re-map which could essentially give you the functionality you are looking for?
Any idea that has not received any kudos within a year after posting will be automatically declined.