Guillaume Lessard

QUOTE(TobyD @ Feb 20 2008, 03:51 PM) That could get really old if what you want to do is look at the current block diagram. Currently anything that pops up is fairly small and non-intrusive. If LV starts popping (reduced) block diagrams whenever the mouse pointer is stopped for 2 seconds... I can feel a surge of annoyance already!! Pop it when a modifier key is down. Or show it in the context help window when a modifier is down. (Ah, the annoyance ebbs...)

QUOTE(Aristos Queue @ Dec 13 2007, 01:21 AM) Well, then. I guess I'll try to make suggestions more often!

QUOTE(Aristos Queue @ Dec 12 2007, 01:22 PM) The part where a new probe doesn't automatically add itself to the class is quite irritating in itself; having to dig for it, move it, and then convince it to be part of the class... honestly I find it quite an energy barrier! Also, popping up on a class wire and creating a new probe there is not exactly intuitive -- seems like a pre-LV8 way to do things. Why not have the option of creating a probe VI directly from the lvclass/project window? (In a related gripe, creating and editing the mnu file for a class pop-up palette is also too circuitous). Should have the option to create "probe" and "palette" in the same menu as "static dispatch VI" and "dynamic dispatch VI". I'll stop here, because my LV machine is not in running condition and I can't compare wishes with reality. I'm sure I could come up with suggestions if I sat in front of it and thought about improvements; right now I mostly just remember that I was frustrated with the process of writing a probe!

QUOTE(Aristos Queue @ Dec 12 2007, 11:22 AM) Very good. Now why is it so hard to make a class probe? The reason we have the knee-jerk reaction of wanting to see object contents as a standard cluster is that it's rather painful to see the data. It's feasible, but it's a lot of preliminary work for someone who is just trying to learn LVOOP and understand what's going on! Helpful code-generation tools are needed! =)

QUOTE(crelf @ Dec 12 2007, 09:42 AM) I completely agree with this. I wrote a GUI with multiple event loops and it rapidly turned into a nightmare. I converted it to a single event loop with message passing. Each tab (which represent modes of operation in my case) has its own message processor, and it just ignores any messages that don't make sense. The code is much more understandable now...

Hi, It seems to me that the design paradigm for distributed control involves message-passing, not uber-global shared-variables. The shared variable is, first and foremost, a global variable. It's useful when slapping something together quickly, but it can easily become a problem for scalability. And scalability is the problem you're going after! Multiplying the shared variables for each door you want to control seems to be pretty much a no-go. With a single-mailbox system (one shared variable), how will you guarantee that each message is received? Will you leave each message in the mailbox for a minimum amount of time? Will you wait for a confirmation that the message has been read? What if one door-controller locks and never gets its message? If each entity in the system has its own "mailbox" that works without extra programmatic configuration (i.e. without having to add shared variables all the time,) you get the advantage of multiple shared variables with the advantage of the single-mailbox system. That's what you'd get with message-passing. It will probably be more work upfront, but once it works, it'll be done.

QUOTE(Jim Kring @ Aug 24 2007, 10:18 AM) I agree with Tomi that it's not a good idea. People shouldn't have to relearn every concept under a new name just to find out that they already knew about it... QUOTE(Val Brown @ Aug 24 2007, 01:11 AM) It really doesn't make sense for NI to alienate and disenfranchise its long-standing, advanced programming community that has "come up" using dataflow. Why have dataflow-based programming precluded by enforcing classes? Val, have you even looked at LabVOOP? It's Dataflow! It's Objects! It's unique! It's, well, LabVOOP. I'm pretty sure LabVOOP did more to "alienate" and "disenfranchise" the users most familiar with OOP than any other group. Getting them to rally around it has obviously been a problem...

I have used LVOOP in one part of an application as I was refactoring it. The result was a little messaging library that I found quite satisfying, and as a result I'd like to use LVOOP some more! I was expecting to be able to do so after the new version came out. However, the meat of my LabVIEW work involves the RT module, and so I still can't use LVOOP very much at all. That's very unfortunate.

It seems that there are still no LV Classes in the real-time module, though. That's unfortunate! What are the reasons this is so?

QUOTE(george seifert @ Jul 30 2007, 02:45 PM) You can send your data along to another, lower-priority loop using a queue. File operations are some of the first things to send to another thread if you ever have problems with code that hiccups...

Relating to that, is there an easy way to edit that mnu file other than editing the whole palette? That's the only method I've found, and I must say it feels very very kludgey -- especially since I only want that class palette in the pop-up menu...

Thanks for the info, JP.

Hi, I'm working on a little messaging framework to send data over TCP between two machines. That's simple enough, and I thought I'd save myself a bit of work when sending complex data types by converting them to variants and then flattening the variants to strings. What I didn't realize is that "Variant to Flattened String" doesn't really flatten into a string, but into a string and an array of integers. That doesn't really help for sending data over TCP, unless I cluster that up, flatten the cluster and send that. Ick. Is it necessary to use "Variant to Flattened String"? My cursory testing indicates that "Flatten to String" works fine for variants; I haven't found a case where it fails. Note that I'm not interested in using any of the fancy features of variants in this case. The online help and examples do not bother to go into the whys and wherefores, and so are unhelpful for this! Thanks for illuminating me,

QUOTE(Tomi Maila @ May 29 2007, 11:13 AM) I fear this is mostly a rhetorical question; I doubt the answer would be interesting. Likely along the lines of "Because we could" or, at worst, "because of paranoia."

QUOTE(Jeff Plotzke @ Feb 18 2007, 12:58 PM) I expressed myself poorly; when I was originally trying to figure out what architecture to use, I tried repeatedly polling a local variable tied to a button. That (kind of) worked, but it was very ugly. I ditched that solution because it wasn't very scalable, and in any case the front panel added jitter to my app!