shoneill

QUOTE(Justin Goeres @ Aug 23 2007, 05:40 PM) Using THAT as a touchscreen would be a great workout! Shane.

QUOTE(blueshrimp @ Aug 21 2007, 11:26 AM) I don't know why your 2D array isn't working, but..... why don't you try passing it as a 1D array (re-shape the array to a 1D array). Since your array is square, you can re-shape the array within the DLL quite quickly back to a 2D array. You also can have a check to see if the size of the array really is a square number (1,4,9,16,25,36 and so on). I might be wrong, but I think the re-allocation of an array from 2D to 1D where the overall number of elements remains constant is a trivial operation in LV, requiring no re-assignment of the data, just the Type descriptor. Again, amybe I'm way off here, but that's my take. Shane.

QUOTE(Eugen Graf @ Aug 16 2007, 11:18 PM) Yeah, I understand. You don't need a full Path to open a reference to a VI in memory. Once you have the reference open, you can get the path there. I reckon the path is part of your problem. http://forums.lavag.org/index.php?act=attach&type=post&id=6656''>http://forums.lavag.org/index.php?act=attach&type=post&id=6656'>http://forums.lavag.org/index.php?act=attach&type=post&id=6656 Any reason why this shouldn't do what your original code wanted to do (Differences in output handling excepted)? It works on my 8.2.1 in development mode. How you get the single control is entirely a different story of course. Shane.

QUOTE(Eugen Graf @ Aug 16 2007, 10:25 PM) On a side note, AFAIK, if the VIs are in memory (which they'll have to be to be front-most ) you don't need a full path for the "open" command. Just a string of the VI name will do. Why shouldn't this work while programming? I think it should. Ah. You're building the paths from your "App" instance. While programming, this is LabVIEW itself I believe. In an EXE it's your build program. I think you need to switch paths depending on whether you're running a built program or within the development environment. Or you can just get "All VIs in memory" passing only these strings to the "open" command and forget the path altogether. Shane.

QUOTE(Dan Press @ Aug 15 2007, 05:37 PM) Dan, I do something similar, but I have seperate loops for Event handling (one UI loop), one or more "main" loops, sometimes one loop per instrument and an additional "cosmetics" UI loop. I like being able to define cosmetic states of the FP in a seperate structure. I also don't like property nodes stealing valuable screen space in my main loop. I also make a lot of my programs have optional UIs (mostly reacting to whether they're called as a sub-VI or a main VI). These cosmetic changes can then be really easily switched off when the code is running as a sub-VI. BTW, I love the "For-Loop" coloured labels. Gives a really nice effect. Consider your style copied from now on! Shane.

QUOTE(Ben @ Aug 15 2007, 02:49 PM) OK, I see what u mean now.... I suppose each software architecture, when pushed far enough, will develop some cracks. I wasn't sure you were referring to a single self-feeding loop. I wasn't even aware the term "Queued state machine" referred to this. I remember implementing something like this back in 1997 or 1998 before I even knew it had a name... Seemed like a good way to save time back then. Still, I had maybe 10 or 20 states, most of them quite simple. I actually (I don't know why) try to avoid self-feeding loops. It can be useful in some cases, but as a general rule I avoid them. On a side note, am I the only one who uses a seperate UI loop (hiding controls, scaling charts and so on) for their code? I guess I'm trying to prevent my main loop from switching to the UI thread for hiding and showing controls, but I don't know if it's overkill or not..... Shane.

QUOTE(Ben @ Aug 14 2007, 10:12 PM) As others have already mentioned... Depends on what you mean with QSM. I use event-driven queued state machines quite a lot, especially in connection with UIs (otherwise events don't make so much sense) and I find it really useful, so I certainly won't be abandoning it any time soon. I also don't quite understand the problem with QSM and multi-threading. It's quite possible to have a well multi-threaded QSM if you use the right structure. Of course, I'm takling about an architecture with more than just 1 producer and 1 consumer. Goes more towards component programming than anything else, but it's core is still a QSM. There are cases where Statemachines are simply not neccessary of course. Ben, what do you think they should be replaced with? I await your answer eagerly! Shane.

QUOTE(Aristos Queue @ Aug 13 2007, 10:52 PM) I agree with you 100%. If you refer back to my nugget, you'll see that it's the combination of UI and dynamic dispatch which I was looking for. In the end, I employed an ugly open-end system (based on variants) because I didn't see any other way of doing it. What I would like is somewhere between that and the current system. LVOOP would be perfect if we could place class data directly on the FP for user interaction, but we can't. Hence the idea of having a list of "registered" typedefs for a kind of dynamic dispatching (A Typedefed Control CAN be on the FP). I appreciate that the ability of the compiler to detect wrong data types at compile time is very important, and I'd be delighted to have this functionality. I also tried creating a polymorphic VI with different Typedefed (sp?) inputs, but although no error was created with several polymorphic instances with (essentially) the same datatype but different Typedefs, no polymorphism resulted. At the moment, "With the dynamic dispatching of classes, I can view the class hierarchy and know whether or not a given class has a given functionality. With arbitrary overloading, I become less sure at every turn whether that "add" primitive that I see on the diagram is actually an add." I find it difficult to fully appreciate the real difference between the two cases you're mentioning here. Maybe when I get more familiar with LVOOP things will clear up for me. But I think your example of overloading the "add" primitive is overshooting the mark a tad. The original idea was (when you get down to the bare bones) a convenient way of working with known data structures. I was also trying to demonstrate function overloading, not operator overloading (i.e. Pi() and Pi(2)). In reality, I was actually coming closer to a sort of polymorphism with an extended definition of "Data type". Upon reflection, I have come to realise that the ability to define polymorphic VIs based on their ENTIRE TD would be the right way to go about this. Certainly a long way from arbitrary overloading. To quote one of my posts in my nugget thread (spelling mistakes retained for authenticity ) "I've jsut started working my way into classes, and I love "Dynamic dispatch". I'd also love exactly the same thing for Typedefs. I want a control I can place on a Front panel, wire up to a function and to have the function automatically execute a method "registered" for that exact typedef (such as entering that value into a pre-defined cluster). Replace the control with another Typedef, and the code called updates..... How and where the "registration" takes place, I dunno. Maybe even statically within the VI being called, thus providing strict limits to accepted typedefs." I think the usage of Variants and the admittedly open-ended implementation of my code has actually distracted from what I actually was trying to create. "Registration" is the key here, otherwise you don't get compile-time error checking. So we're agreed on that at least. Shane.

On a slightly unrelated topic, I wish there was the ability to perform "Dynamic dispatching" based on Data type, or even just on Strict Typedefs....... This wouldn't be a "one size fit all" approach, as there need to be a finite number of defined end states, but I think it'd still go a long way to allow some more advanced features. especially when tied to a producer/consumer design. My original post (NI Forum) is here. This, in my opinion, would make some issues in UI programming a LOT more versatile indeed. Haven't tried Xnodes though. Will do shortly. Shane.

<Walter Sobchak> I did not know that. </Walter Sobchak> That would make the available size of any given control rather limited....... Ouch. Shane. QUOTE(Ben @ Aug 13 2007, 02:30 PM)

There still seem to be some files missing in the zip file..... I see you have quite a lot of cosmetic items in the control. This may be the reason for overloading the TD, but somehow I doubt it. Since I can't load all the Ctrls it's hard to comment further. Perhaps replacing all of the cosmetic items with a single bitmap of the required background might help you get around any object limit which may be causing problems? I've very little experience of this kind of control customisation, so maybe someone else is better qualified to answer. Shane. QUOTE(Bjarne Joergensen @ Aug 13 2007, 01:28 PM)

In general any sophisticated OS should not use the filename to distinguish what "type" a file is. However, Windows tends to rely on this quite a lot. Many file formats have a certain header at the beginning of the file, regardless of which file extension it has. If you have some way of identifying an "unknown" file, then this is the way to do it. If it's an unknown file with unknown format, then I guess you're out of luck. You can relatively easily distinguish a PNG file for example. From Wikipedia: "A PNG file starts with an 8-byte signature. The hexadecimal byte values are 89 50 4E 47 0D 0A 1A 0A. Each of the header bytes is there for a specific reason:" Many MSOffice documents also have a certain header for example, but renaming an XLS file to something else breaks it's connection to the application. Windoh!s. Since reading the file contents is quite a time-consuming matter, the file extension (even though it's really only an educated guess) is mostly used. Shane. QUOTE(eaolson @ Aug 12 2007, 05:54 PM)

To the best of my knowledge, "traditional" Type descriptors are limited to 65,536 Bytes in length. Anything leading to an increase of the TD beyond this length will "break" LV. When considering what's stored in a TD, even the names of the controls contribute to it's length. Lots of controls with long names will fill up the available length relatively quickly. AFAIK, NI has changed the storage of many data types recently, so I don't know if this limit still applies. EDIT: I see you're using 6.1. This limit should still apply. I've never encountered this limit before, but this article shows that the "length" of a TD is limited to a U16. Shane. QUOTE(Bjarne Joergensen @ Aug 13 2007, 01:20 PM)

QUOTE(ohiofudu @ Jul 13 2007, 06:31 PM) I normally steer clear of discussions like this, but whatever the nature of "god" then I think the same constraints of mathematics and physics apply there as everywhere else. Out understanding of it might be limited, but Mathematics and Physics (the physical representation of mathematics if you will) is truly universal. Shane.

QUOTE(alfa @ Jul 5 2007, 09:45 AM) I've been to Romania four of five times already, once already with my son. He does indeed like the food. I do too, but the heat in summer can be too much for me. Indeed, learning languages in Europe is more important than in other areas of the world. I'm glad my son's learning Romanian not just because he can then speak romanian, but also because other latin languages like Italian and French and Spanish are very similar and it makes it easier for him to learn these later too. I kind of imagines LV would be a bit expensive for Romania. You know LV 6.1 is available for free download? Would be an interesting was to get people going on LV. Enjoy the conference..... Shane.

QUOTE(alfa @ Jul 3 2007, 08:06 AM) Ce Fac! You're in Cluj? I'll be in Alba Iulia in a couple of weeks. My wife's from there originally. Probably spend more time in Maramures (spelling?) though. Much LabVIEW going on in Romania? As to missing out on String theory, I wouldn't be too upset about that. I don't know if it'll survive the next 20 years or not. One of the few truths in science is that whatever we "know" today looks silly in 50 years time. Apologies for my assault on the Romanian language, I do my best. With my son growing up learning from my wife, I'm kind of learning with him...... Ciao. Shane.

QUOTE(Mike Ashe @ Jun 30 2007, 02:26 AM) Having developed pH electrodes for a number of years, I'm inclined to disagree once one leaves the realm of standard electronics. Once you enter the world of chemistry (or electrochemistry to be more exact) then Protons do indeed flow. OK, normally in the form of H3O+, but they do "hop off" on the boundary to a solid silica network. Si-O- + H30+ <-> Si-O-H + H2O The balance of this equation is defined in part by the pK value of the glass, which in turn more or less determines it's alkali error....... All in all, not something a EE Professor is really likely to come back with as a snappy response.... Now an Analytical scientist, that's a different box of cats. Shane. For non-chemists, H+ is a proton. H (Hydrogen with neutral charge) consists of one proton and one electron. H+, after losing an electron is a proton.