HChandler

O crap! they don't! They must have some sort of handle. Perhaps it could be done by array index number. Are they numbered in the order they're dropped on the panel? QUOTE (Dave Graybeal @ Oct 10 2008, 12:28 PM)

MATLAB also has a pack command PACK Consolidate workspace memory. PACK performs memory garbage collection. Extended MATLAB sessions may cause memory to become fragmented, preventing large variables from being stored. PACK is a command that saves all variables on disk, clears the memory, and then reloads the variables QUOTE (Gary Rubin @ Oct 10 2008, 09:07 AM)

Hey y'all I really dig the openG "fit to largest decoration" function. Is there a quick and easy way to make it into a "fit to named decoration" function? I could put a bunch of related dialogs on the same front panel that way. Thanks

I did not know you could do that with scan string. But then I would not have learned so much about living without pointers :thumbup: . QUOTE (normandinf @ Oct 6 2008, 12:04 PM)

I just realized that I have not updated my profile. I AM using Version 8.6! Thanks for everything.

For security reasons, I cannot do my development work on the a web connected computer. I can't even install non-approved software on my web connected internet appliance. Can I still install open-G.

Oh dang! I guess I should have checked to see if it really worked. Unfortunately I was focusing on another problem. Your example works MUCH better than mine but still requires the input of the vi to be strictly typedef-ed. What I was really trying to do is have a vi that you could pass any old enum (including strictly typedef), and a string and get the position of the string in the enum ( or an error if not). What I really would like to know is if it's possible to pass a strict typedef enum into a non-typed enum. Thanks

I'm not sure you're getting what I mean (or vice versa) Here're a couple of vi's that explain what I'm trying to do. Sorry no pictures, my screen capture (printkey 2000) bombed out.

Say I have a strictly typecast enum that I want to pass into a more generic vi that (for instance) compares a string to the enumeration strings to return the index of said string, and signals if not present. It would be great if the vi could take in the strictly typecast enum and still be generic enough to use with ANY enumerated type. Will settle for downcast outside of vi. Thanks

Alright!!! :thumbup: That demo is is downright usable!! Thanks

One other thing. Is there an easy way to find out what the current position is? or (ok two other things) Is there a quick way to shift the the current view's position to the origin? Thanks

Thanks, This is really helpful. Howard

Here's what I'm talking about. I design a front panel. I set the properties so that when it pops up it has no scroll bars, like a dialog. There may be some controls or indicators someplace on the panel, some are outside of the frame and are meant to be there. Others are carefully placed within the frame to make a nice display. Then, I get some kind of error. I choose the useful option to go to the error. It pans the panel to show the messed up indicator. I fix the problem. Then, I forget to re-frame the panel to hide the bits and pieces. When the program pops up the sub-panel exposes stuff that's supposed to be out of view, indicators or controls are exposed, and even worse, some important control/indicator gets shoved out of the picture. Is there any way to lock the frame, or set a default view that always snaps back at run time to what I want it to be in spite of what happens while the program is not running. Thanks, Howard

That gol darn files tab is probably the worst possible thing to do since when it crashes, it leaves multiple same-named vi's wherever they were whenever it crashed. I can't beleive that LV released this "feature". The way it is it's just a booby trap. So If I'm reorganizing, I should move things around the filesystem before firing up LV being careful not to allow multiples of same-named vi's around? Also, what about lvlibs. Should I use them or not? Should I take things out of them before moving things around? How about LLBs? I don't use them now but are they a better way to go for portability? I need a strategy that works.

I guess it's deterministic, but I havent been given the decoder ring that clues me in to what it's going to do in response to something I do. OK, Enough of the whining. A question. LV will only crosslink with vi's on the disk/volume/partition where the parent vi lives? True? If this is true, what I should always do when reorganizing projects etc is to create the new development space on a pristine disk. Yes???? OK, a little more whining. My biggest mistake was trying to use the files tab in the project manager to reorganize my development space. Every time I try and use it, it crashes the entire project!! It seems like the files view is how LV was trying to deal with the paradox of linking with fixed linkages that are already loaded in memory. This would be fine if they want to do some juggling behind the curtain. But, it seems to really hose things when, as it allways seems to do, it crashes while the balls are still in the air.