eaolson

I've been playing around with images, and have come up with the attached set of classes to hopefully eliminate the somewhat complicated way LabVIEW handles images loaded from disk. The "flattened pixmap" approach is a pretty clever way to handle both truecolor and indexed images in the same data structure, but it's unnecessarily complicated in my book and can lead to some problems if the image you load is not the image you expected at design time. The transparency aspects of loading the images may not be exactly correct, which is why I haven't put this in the CR yet. It seems LabVIEW doesn't load the alpha channel exactly as it's described in the help text when the image is very small. This is my first real foray into LVOOP, so I would appreciate any critiques or comments anyone would offer, on anything from whether it works as it should to the OOP design.

QUOTE(alukindo @ Aug 31 2007, 11:07 AM) There's no way that I'm aware of to discard the value change event while the slider is still sliding. I got around this by catching the Value Changed event, the Mouse Down event for a slider, and the Mouse Up event. 1. On the mouse down, put a control reference to the slider in a shift register, and the current value in another shift register. 2. In the mouse up case (which is not specific to a particular control), check the reference and if it is valid, fire the value changed event using the Value (Signaling) property. Also invalidate the control ref in the shift register. 3. In the value changed event, check the value of the control reference in the shift register. If it's valid, the mouse is still down and do nothing. If it's invalid, the slider is no longer moving and handle the event.

The sad part is that this still makes more sense than the Fifth Dimension.

QUOTE(Tomi Maila @ Aug 24 2007, 05:05 PM) I disagree completely. We don't need to be introducing new terms that adequately describe things that have existing terms. LVOOP is object-oriented programing. If people are assuming by-reference behavior, we need to fix their assumption, not introduce new terms. If anything, I think the term LVOOP needs to go away and be replaced with just plain OOP. LVOOP smacks to me as an attempt to brand a preexisting concept with the LabVIEW name. We don't talk about CppOOP or JavOOP, why should OOP in LabVIEW be any different?

QUOTE(Aristos Queue @ Aug 22 2007, 06:16 PM) I'm currently playing around with objects in a project I'm doing for fun, mostly so I can learn how they work. I was very frustrated at the beginning trying to find information on exactly how LabVIEW classes worked. There are a few pages in the online help, but they're not particularly well organized. For example, I'm still not entirely clear on how an Override VI is different from a dynamic dispatch VI because nowhere in the help is an Override VI defined. I'm also a bit muddy on dynamic dispatch VIs themselves. Like, if I have a heirarchy A -> B -> C, and I want to create a dynamic VI for A and C, do I have to create one for B as well? How does Call Parent Method work in that case? How do classes, projects, and project libraries overlap and work together? Am I supposed to be putting my classes inside libraries inside projects? (Project libraries bug me too, but that's for a different day.)

QUOTE(Pana-man @ Aug 20 2007, 11:47 AM) Without going into your class heirarchy as others have done, it sounds like you're assuming a child class can access the data of the parent from which it is derived. This isn't correct. LabVIEW only has private data, no public or protected data, no friend classes. Accessing a data member of a class higher in the heirarchy requires a member function of the parent class.

?oot ,tfel-ot-thgir gnitirw trats ot gniog uoy erA ?txen s'tahW Shun the lefties! Promote standards-compliance!

QUOTE(NormKirchner @ Aug 17 2007, 10:02 PM) Hmm, I can not cast a picture to a string. Do you mean Flatten to String instead?

QUOTE(NormKirchner @ Aug 17 2007, 12:43 AM) Ah, I see. That's very clever. It does mean that every time you redraw the picture the entire string has to be rendered. In the case of many graphical primitives, that might be slow. Flattening and unflattening the picture forces it to become an array of pixels. I imagine there is a CPU/memory tradeoff there. Hmm. I just noticed Draw Rect has an unnecessary type coersion that doesn't seem to be in any of the other picture functions.

QUOTE(NormKirchner @ Aug 16 2007, 01:30 PM) I'm not quite clear on what you mean here. I ran into an update rate problem when working on the Game of Life that's in the CR. The displayed picture consists of many thousands of squares overlaying each other. When I just used Draw Rect a bunch of times and fed the output to the picture control in a loop, it was very slow. Scrolling the picture if it was too large for the control was disastrous; the redraw couldn't keep up. I got around it by using Picture to Pixmap and Draw Flattened Pixmap in conjunction. Basically, it forced the picture data to be rendered to a raster image. There are two issues to this, I think. One, the instructions in the picture data must be rendered to a rectangular block of pixels. Then those pixels have to be displayed in the picture control. So the data is handed off to the UI thread at some point to update the control. It's not clear to me if the rendering happens in the UI thread or not.

QUOTE(NormKirchner @ Aug 16 2007, 10:27 AM) It seems to me that there are two somewhat distinct issues: LabVIEW pictures and raster images. All the picture functions (Draw Rect, etc) simply append an instruction for drawing a geometric primitive, but don't actually draw it. Once you get more than a thousand of those instructions, rendering the picture to actually display it becomes slow and unwieldy. It looks similar to QuickDraw, which makes sense considering the Mac-origin of LabVIEW. When dealing with an external image, the picture data just sort of puts a wrapper around a raster image. I've been working with microscope raster images a lot lately and reading them from disk (and across a serial port) becomes complicated if you want to do anything other than load and display them. The nomenclature is confusing (pixmap?) and not used consistently. That's the angle I was coming from, but it sounds like you've given this a lot more thought. I would be interested to see what you've got so far. QUOTE(Aristos Queue @ Aug 16 2007, 10:29 AM) Then you can avoid all the duplication of code for the 8, 4 and 1 cases by putting that functionality on the common parent, but you leave yourself room for specific behavior for the 8, 4 and 1 cases if you need it at some point in the future. Thanks for your suggestion. I'm really starting to think that's the best direction to go.

I've been working with the LabVIEW picture functions lately and am rather dissattisfied with them. Partly for that reason and partly because I wanted to play around with LabVIEW Objects, I've been fiddling around with creating a object-oriented wrapper for some of the picture functions. One of my main objectives is to completely hide that confusing "image data cluster." However, I have several ideas on how to implement the objects and keep waffling on which is the best. I'd like to ask for comments and suggestions. 1. Create a single Image object. This would handle loading and saving of image files and could be converted to/from a Labview picture datatype. It would basically be a wrapper around the image data cluster, with different case structures depending on the image depth. 2. Create a parent Image object and child Image24, Image8, Image4, and Image1 objects for 24-, 8-, 4-, and 1-bit images. This was my first thought, until I realized it's a significant duplication of effort. Internally, there is no difference between 8, 4, and 1 bit images except for the length of the colors array, so handling these separately didn't really gain me anything. 3. Create a parent Image object and child Truecolor Image (24-bit) and Indexed Image (8, 4, 1 bit) objects. This seems to me to be the most elegant solution, but I'm worried it will bite me in the butt later on. There might be some operations on indexed images that have no analogue to RGB images (i.e. changing the color palette), so I'm not sure how to handle those yet. LabVIEW also doesn't handle transparency very well. It will load a full alpha channel for a 24-bit image file, but not an indexed image, even if it's present. Furthermore, the picture control can only handle 1-bit transparency (i.e. fully transparent/fully opaque). I wonder if that's likely to change in future versions. So I'm thinking of maintaining the 8-bit alpha channel for 24-bit images, but not for any of the indexed images. Your thoughts/comments/suggestions/ridicule would be welcome.

The site works just fine for me in Firefox. QUOTE(PaulG. @ Aug 14 2007, 12:32 PM) What functionality you get in IE that you don't get in Firefox? If anything, it seems to me you get less in IE. You can't extend it nearly as easily; I can't live without mouse gestures anymore. Hmm, or AdBlock. There are also enough @#$!%$ CSS positioning hacks necessary to get stuff to look right in IE that it always drives me up the wall.

Since I'm a practitioner of the Dark Arts, I don't really work with Macs, just Windows. My last significant experience on a Mac was with OS 9, so I know very little about OS X. I know that pre-OS-X, Macs used to store the file type and other metadata information separate from the file itself, so the the file name was no indication of what type a file was (i.e., no file extension). Is that true on OS X, or does it use the file extension? I guess my larger question is whether or not there is a platform-independent way to determine a file type (png, doc, etc.)? Or does everyone in practice just use the file extension?

QUOTE(LV Punk @ Aug 10 2007, 06:37 AM) \begin{rant} I saw the monstrosity that is the redesigned Office toolbar, excuse me, "ribbon," only a couple of weeks ago. It strikes me as a perfect example of changing things that don't need to be changed, just for the sake of changing them. Really, is File, Edit, Insert, Format, etc. really that difficult for anyone to understand? Word has been around for 10+ years and this complete redesign of the toolbar means I have to hike up a learning curve to do the exact same things I was doing before. Not to mention the thing is a usability nightmare: one of the rows of buttons consists of icons, one of text, one of text and icons. None are the same height and one of the buttons actually straddles two toolbars! Maybe Microsoft consulted an efficiency expert, who decided things needed to be grouped more logically, but were people really having trouble finding Tools:Options? The LabVIEW 8+ style palette still bugs me, too. Maybe I'm just getting inflexible in my old age.

QUOTE(adriaanrijllart @ Aug 8 2007, 08:27 AM) Be aware that this introduces a bias into your data, namely that you're getting the derivative from the left side of the function. Basically lim(dy/dt) as t -> t_i+. This will only be strictly true if the second derivative of your function is zero. It maybe a small enough effect that you don't care, though.

QUOTE(David_A_Moore @ Aug 3 2007, 05:24 PM) It sounds like what you want is this: http://creativecommons.org/licenses/by/3.0/''>http://creativecommons.org/licenses/by/3.0/' target="_blank">http://creativecommons.org/licenses/by/3.0/ Just a few simple bullet points. To be honest, I wouldn't touch these outside of a hobby project for the very reason that it's not clear if I could redistribute them. It seems to be your purpose to give these away, but five years from now, after you're bought out by Giant Conglomeracorp, their lawyers might disagree.

QUOTE(Aristos Queue @ Aug 3 2007, 03:49 PM) See, answers like this are why I bother to ask questions. I had been thinking of the refactor reason myself, but using it for range checking makes it go from "handy" to "damn useful." To be honest, I'm surprised that subVIs don't enforce the Data Range criteria for front panel controls for this very reason. QUOTE This is known and already fixed in a future version of LabVIEW. *sigh* So just how many working branches of LabVIEW are there at NI at any one time? Or do you just occasionally spin off the "cool stuff that's working" into a new version?

QUOTE(Aristos Queue @ Aug 3 2007, 02:47 PM) I'll admit my ignorance and confess I've never understood these benefits. If you're talking about get() and set() methods working on a private data member, I don't see any significant benefit of doing things that way compared to just using a public data member. You lose both data encapsulation and data protection. I assume these benefits exist, I just don't understand what they are. Visual C++ went so far as to add the property keyword which sort of automates the creation of a data object along with its get and set accessors. QUOTE I *sooooo* agree. :-) I have been told that to be a first class citizen, a feature has to have users first. There's a chicken/egg problem here, but I have been slowly assembling a chicken from spare parts. So you're creating a Frankenchicken?

QUOTE(george seifert @ Jul 30 2007, 03:03 PM) It would probably require a lot of rearrangement to your code, but you could write a string to a log file between each step. "Read COM1, Read COM2, Write TDMS, Done" and so forth. At least it might tell you where it was getting stuck. It's not clear if you mean that one loop iteration takes longer than previous ones or if the whole thing just stops. Are you building arrays as you go? I've had loops slow down if they kept building larger and larger arrays. How much data are you collecting? If a large chunk of memory has to be swapped to disk that can slow things down, depending on your disk.

When using the Tab key to move from value to value in the Edit Items screen for an enum, ring, or menu ring, LabVIEW will sometimes delete the previous value. Happens in 8.20 and 8.2.1. 1. Put an enum on the front panel 2. Right-click and select Edit Items 3. Click the first entry to get a cursor in the Items column. 4. Type the first text, say "a". 5. Type Tab to go to the second entry. 6. Type the second text, say "b". 7. Type Tab to go to the third entry. 8. Type the third text, say "c". 9. Type Tab to go to the fourth entry. 10. Type the fourth text, say "d". 11. Type Tab to go to the fifth entry. The error appears. The third text string is now blank and the Digital Display column for the third and fourth entry is also blank. The cursor has moved to line 5, but the row is greyed out as if it were still inactive. When starting with an empty enum, this seems to consistently happen when tabbing from the fourth entry to the fifth. When tabbing around in an enum that already has values in it, it only seems to happen at the end of the list and it starts adding new values. This doesn't happen using the Enter key in steps 5, 7, 9, and 11 above. CAR # 4BO8IDYT.

QUOTE(VRPaul @ Jul 26 2007, 07:24 AM) Generally the initial state of a button (i.e., when it's not pressed) is False. So it sounds like you have something that is normally false wired to a Continue if true terminal, so it stops. Usually, it's a Stop button that's wired to the While loop's terminal. QUOTE I have also trouble with making an .exe of my program. i'm saving it with options, selecting application distribution and no password change, saving it with extension .llb. .... and then after restarting labview, i need to choose "build application" in the menu Tools. there's the problem, "Build application" is not listed in the menu "Tools". i'm working with LV 6.1. To build an executable, you need the http://sine.ni.com/nips/cds/view/p/lang/en/nid/10731' target="_blank">LabVIEW Application Builder, which is a separate add-on. I really don't know what to do if you need this for an old version of LabVIEW.

QUOTE(rolfk @ Jul 22 2007, 03:42 AM) Yes, that's exactly what I can not do. The Project property contains Targets[], an array of all the targets in the project. They are of type Target Item Refnum. Open VI Reference wants a "LabVIEW Application Reference". Using the Target refnum in place of the Application Reference doesn't work (broken wire), nor does typecasting it to an Application Reference (error). Application Reference is not even in the LabVIEW object heirarchy, so I can't use To More Specific/To More Generic Class. Attached is what I was trying to do. QUOTE(Aristos Queue @ Jul 22 2007, 11:34 PM) Every application instance has its own application refnum. You can have multiple application refnums for the same LabVIEW.exe on the same machine. For example, if you open two LabVIEW projects, each one has its own application instance, and you can get the app refnum for each of those and then open VIs into those app instances. My situation is slightly different. I have one project that contains a "My Computer" target and a "RT PXI Target". Each of these seems to have its own application instance as well. If I open my real-time VI under the RT PXI Target by double-clicking in the project explorer window, LabVIEW knows to pull some RT-specific subVIs from <labview>/Targets/NI/RT/vi.lib and does so automatically. No TCP connection to the target is made. If I wire the path to the VI to Open VI Reference, LabVIEW looks for these subVIs in <labview>/vi.lib and can't find them. The Project property node has a property that is the application reference for the project. There isn't a corresponding property for Target Item.

QUOTE(yen @ Jul 21 2007, 02:19 PM) So you're saying this is the post has the Number of the Semi-beast?

After posting this question on the OpenG forums, I was doing a little poking around and now seem to be stuck. Is there any way to open a VI programmatically (as with Open VI Reference) in the context of a particular application instance? I don't mean an application reference (from Open Application Reference), because that actually opens a TCP connection to a VI Server instance running on some other machine. When I've got a LabVIEW project with an RT target defined, I can open one of the VIs designated for that target in an RT application instance. It pulls some target-specific subVIs from a different vi.lib than the standard. It doesn't actually form a connection to the target. I can get refnums for the project itself, and the targets, but can't seem to do much with those refnums.