Leaderboard

A yes! I remember that. The Picture control does maintain a background pixmap that is redrawn on front panel refreshes and pixmap extractions. And it is in fact independent of the size of the actual Picture Control although I think that for refreshes of the image it will clip the drawing operations to the visible area. But did you notice the rect input to the Picture to Pixmap.vi function? With that you can define a clipping rectangle to which the returned image will be restrained! From the help to that function: rect is a cluster that contains coordinates that describe the bounding rectangle of the image you want to convert. The default is to return the entire image. Horizontal coordinates increase to the right, and vertical coordinates increase to the bottom.

If you want to see a Certified LabVIEW Developer sample exam written using LabVIEW classes, I am uploading one here. I built this over the last four hours in response to comments in another LAVA thread which correctly pointed out that a sample CLD written with classes was not available for review. If you wish to comment on improving this class-based sample exam or ask questions about how it works, please post them here. If you wish to debate whether LabVIEW classes are worth using or whether they are overkill for real apps (including for the CLD exam itself), or any other philosophy, please post in the original thread that spawned this. The sample exam that I did was ATM version 2 (I am attaching the PDF to this post for ease of reference). After 4 hours, I have the solution posted below. It is not a fully fleshed out app -- it is exactly what I have finished after 4 hours and would have turned in on the exam. It is very similar to what I turned in for my actual exam, although I will note that for my actual CLD, I specifically brushed up on file handling and had that working. Tonight, I was unable to recall my cramming, so that just got dropped (but documented as a TODO!). Top level VI is ATM UI.lvclass:Main.vi. This VI takes an ATM UI object as input in case configuration options are added to this application in the future -- those options are already part of the UI loop. Issues that I know of: File I/O is not done, as I mentioned above. The display strings are placeholders ... I didn't type out all the proper strings. There's no way for the user's name to be displayed when they put in their card. Although I documented the VIs, I did not fill in documentation into the classes themselves and probably should have. Other than that, I think it all works given the limited testing I was able to do within the 4 hours. I have no idea why I felt the need to make setting the display message go through an event instead of just setting the local variable every time. I think i had it in my head to bottleneck the localization, but that doesn't work, of course, because you have to be able to format information into the strings. That should probably be removed entirely. I did build a message abstraction from ATM UI to ATM, but I didn't build a messaging abstraction from ATM to ATM UI. Why? Because I thought the data needed to respond was always the same. It wasn't until later that I decided that was a mistake, but I figured I should finish out this way. Building a true abstraction layer for completely isolating the ATM from the ATM UI is probably more than can be done in the 4 hour block unless you've got some scripting tools to back you up -- we'll have to see if it's reasonable in LV 2012 (without going into detail, assuming the beta testing goes well, there will be tools to help this exact problem in 2012). 100928-01.pdf AQ_ATM2.zip