Aristos Queue

This was reported to R&D (# 4BUEOEJ1) for further investigation.

QUOTE(Michael_Aivaliotis @ Jul 30 2007, 01:42 AM)

I'm not aware of this. You must have meant Mozilla... Uploading works fine in Firefox.

Mozilla on my PC has the bug. But Firefox on my Mac-Intex laptop also can't upload. I flip over to Safari when I want to post a file.

QUOTE(abuch06 @ Jul 27 2007, 10:07 AM)

I'm having issues all over the place... I think my company put up a block on posting things on the internet, which means I have to somehow find the answer to this problem by explaining it rather than showing you. It's not difficult and I feel retarded about it but I can't figure it out:

Try a different browser. I can't upload images when I'm using Firefox, but I can using MSIE and Safari. I believe Michael is aware of the issue.

QUOTE(Tomi Maila @ Jul 28 2007, 09:31 AM)

Eh, there is not a main level VI in the example. Pehaps you should have an example that is runnable as well i.e. there is a main level VI.

I believe that you are meant to open and run

ExecutionControl.lvclass:controlMainFlow.vi

That is the main VI.

Posting an image makes this easier for everyone to diagnose. Do you have a screenshot of your block diagram available?

QUOTE(dcooper @ Jul 24 2007, 10:44 AM)

Please add some sort of resizing option like the anchor property in .NET so I can specify how each front panel object is to be resized when the front panel resizes.

The current options such as "Scale object with pane" just doesn't cut it.

Dcooper, the LAVA site isn't associated with NI and most of the NI folks don't read it. For these types of suggestions, you should go use NI's online http://digital.ni.com/applications/psc.nsf/default?OpenForm' target="_blank">Product Suggestion Center.

QUOTE(rolfk @ Jul 24 2007, 12:21 AM)

This sentiment! Is that official NI policy now?

Nah, just my personal thought on the situation. I'm not privvy to the conversation that lead to the licensing of scripting. It just seems that no one around NI minds when the advanced customers dig stuff out of "LabVIEW's attic", but when it starts showing up among the general user base and creating a support burden, there starts to be grumbling about "never intended that to be opened up."

Yes.

QUOTE(rolfk @ Jul 23 2007, 05:18 PM)

But someone at NI must have forgotten that. There is or maybe used to be a code example on the Developer Exchange Site exactly with the MoveBlock function. So you hardly can call the Library:LabVIEW trick in the Call Library Node to be a well kept secret anymore.

True. Which is why licensing got applied to scripting. You probably don't want to promote the publicity of this lest similar protections come to the callback.

QUOTE(Yuri33 @ Jul 22 2007, 10:36 PM)

Is there a list of undocumented calls like this to the LV library?

No, and using such callbacks is a trick we go to great lengths to prevent folks from doing.

QUOTE(eaolson @ Jul 19 2007, 09:31 AM)

After posting http://forums.openg.org/index.php?showtopic=619&hl=' target="_blank">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.

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. Your comments about these opening TCP/IP connections apply ... LabVIEW treats communication between two app instances as if it were communication between separate machines. This makes it possible to develop multiple apps on the same machine and have those apps work together at runtime whether they're deployed on the same machine or different machines. If the apps are on the same machine, LV does optimize out some of the communication overhead unless you explicitly open the application refnum using a TCP/IP port number (wire to the port input on the Open Application Reference primitive).

Any VI that you open in the host computer's targeted application instance will be deployed on the target when you run that VI. The host's targeted app instance is a proxy for what goes on down on the target.

QUOTE(lraynal @ Jul 20 2007, 02:23 AM)

Don't forget, as well, that you can put *.dir as a pattern to see only the Directories when you browse!

Is that platform independent or just MS Windows?

QUOTE(chrisdavis @ Jul 20 2007, 03:51 PM)

IMAQ Mempeek should do what you want, or you can check this thread to find other ways.

Thanks.

QUOTE(Tomi Maila @ Jul 18 2007, 05:10 PM)

I've understood that all ancestor classes need to be in the project explorer during the development of any decendent class. I may have misunderstood. Am I wrong here?

The ancestor classes do have to be found on disk, but they do not have to be added to the project tree. The ancestors will show up under Dependencies.

QUOTE(Gavin Burnell @ Jul 19 2007, 11:28 AM)

The next version of LV will have a VI in vi.lib to deal with this to let you get the actual type.

For the moment I'm not really coming up with any helpful solutions.

QUOTE(Paul_at_Lowell @ Jul 19 2007, 01:12 PM)

AH. Here we go... The attached VI will give you the name of the class ON the wire, as opposed to the name of the class OF the wire.

http://forums.lavag.org/index.php?act=attach&type=post&id=6422''>http://forums.lavag.org/index.php?act=attach&type=post&id=6422'>http://forums.lavag.org/index.php?act=attach&type=post&id=6422

Does anyone have a standalone DLL that has a function which, given a memory address, returns the byte, word or int at that memory address? It would be useful for a hack I'm contemplating, and I don't feel like coding a DLL for a one-off project.

Try putting all of your calculations into a subVI. On the top level VI, only have the actual controls that make up your user interface. Then the temporaries that you're using for variables don't show up in the Event Structure dialog.

QUOTE(Paul_at_Lowell @ Jul 18 2007, 02:36 PM)

OK, I retrieved the type string from the 7.x version, which returns an array. I need to compare some of the elements in the type string array, not all, though. (If I include all the comparison shows a mismatch as before.) How do I know which elements are necessary and sufficient?

*blink* Really??? They should be the same array if they're the same type... oh, wait... the type name. Crud. Yeah, that would skew the result. The data type includes the "name" of the wire in the output array.

Argh. I was trying to be helpful. Sorry for the red herring.

QUOTE(Tomi Maila @ Jul 18 2007, 03:43 PM)

I was on vacation. A much needed one.

QUOTE

No. There have been so many usability challenges raised to this idea. I like the idea, and a couple of members of my team have tackled it, but it ends up being unpleasant. Basically, recall the complaints that occur when LV moves the palettes around between versions of LV. Now imagine if the palettes changed around every time you edited your class. The grumbling gets loud. Then there's the constant debate about *which* menu should appear first -- if you popup on a child wire, should you get a single palette with all the methods of child and parent and grand parent? Or should these be separate palettes? Should the parent be on a subpalette or should the child be on a subpalette?

All in all, I've decided it is low priority -- if you're creating a class to be reused, when you're done with development you can create a palette by hand and set it to appear in the context menus (using the class' property pages). If you're still developing the class, just use the project tree as the palette -- it's close at hand generally.

QUOTE(Ben @ Jul 18 2007, 01:06 PM)

Yes.

Ben

Ben, I think the emoticon that you were wanting was:

QUOTE(xtaldaz @ Jul 18 2007, 11:04 AM)

Ouch! Seeing as how Doug and I took the very first LabVIEW 2.0 class together, that statement hurts a little. Pretty soon LV will be older than most of the people using it.

Story: One of our interns made a change to LV's source code that broke the exe. Our chief architect, in a mock scolding, said, "You be careful! That code is older than you are!"

QUOTE(Paul_at_Lowell @ Jul 18 2007, 11:19 AM)

By the way, it is not sufficient just to compare the "data string" output of "Flatten To String" because the data is encoded in the data string. (We have the same problem the built-in Search 1D Array method has.) We have to extract the information we need from the data string (as Gavin has done in his solution). Is the class name the only information we need for the comparison?

Pop up on the Flatten To String node and select the LV 7.x compatibility mode. This gives causes the node to add a type descriptor output. You can then compare the type descriptors for equality. Note, this allows to test for *equality* ... it won't help if you're looking for "this class or any child of this class."

QUOTE(Val Brown @ Jul 17 2007, 02:32 PM)

Does it have to be copyrighted, trademarked or patented?

Yes. Because otherwise someone will *find* a way to copyright, trademark or otherwise patent it and then charge you license fees.

Fix the US legal system first, then we'll fix the naming conventions. :-(

You're facing the same problem that an array of clusters faces when you want to search for a cluster based on a single field instead of the entire cluster. The only way around it in LV is to write a new Search 1D Array that checks for whatever criteria it is that you're searching for (you can write this generically and then take a VI Server refnum to provide the comparison routine, too). This has been done by many people and I think there are implementations of it on LAVA somewhere.

QUOTE(Michael_Aivaliotis @ Jul 10 2007, 03:44 PM)

Yes, this works well.

One other solution is to use rendezvous. Rendezvous are tailor made for this use case. Now you know where you can use those obscure functions.

I used to recommend the rendezvous for this case. But after a while I started noticing that although rendezvous solved the initial problem of synchronizing two VIs, many programs eventually turned out to need more communication between the VIs that went beyond just a "go" signal. So I've just been recommending queues/notifiers right from the start so that the data channel exists if it turns out to be necessary.

QUOTE(John Rouse @ Jul 11 2007, 12:42 PM)

Id be interested in who is using LV classes and for what purpose.

My exp with LVOOP so far has been guarded.

I'll be free to talk about NI's use of it at NI Week, but not until then. All I can say is it is pretty extensive for such a new feature. Of the new features I've seen added to LV over the years, the event structure is the only one I can think of with a bigger impact on programming style of our G programmers. NI's overall adoption has been somewhat limited by the lack of support for classes under RT and the embedded targets, something I hope to remedy in the coming years.

QUOTE(Gavin Burnell @ Jul 10 2007, 03:25 PM)

Ahhh, so it wasn't just me then. Actually it hadn't been a big enough problem for me to spend the time trying to work out why one of my classes always crashed when probed - I'd sort of assumed it was something to do with the class data structure, but I hadn't got as faw as working out some test cases. Good to know it'll be fixed...

In my best Mrs. Cake voice (from Terry Pratchett novels):

Ah, lad, ye gots to report ye crash or how canaye fix yon bug?!