LabVIEWBlog - Viewing Archives: October 2002

Well, on another note... Today

Well, on another note...
Today was the last day of our on-site system installation. We just finished installing a LabVIEW controlled Radome tester. Basically this involves testing airplane nose cones.
It was tuff, when I have pictures I will post.

Posted by Michael Aivaliotis at 12:12 AM | Comments (0)

Insane GURU Object

I really think that LabVIEW guru is insane! I thought I heard the last of him but here is the "guru" again. Back to his old tricks. Here we have the classic case of someone who is in need of psyciatric help. His latest Info-Labview email with my assesment...

Continue reading "Insane GURU Object"»
Posted by Michael Aivaliotis at 11:33 PM | Comments (0)

Well, I think the LabVIEW

Well, I think the LabVIEW guru guy won't be spamming us with garbage posts on info-LabVIEW for a while. This was my response to one of his emails:

Continue reading "Well, I think the LabVIEW"»
Posted by Michael Aivaliotis at 11:14 PM | Comments (0)

Well, today I think I

Well, today I think I had enough of the LabVIEW guru. He posted the following:
John,'
Use the VI server with window properties to set locations and sizes of windows.
LabVIEW guru.
>To clarify my question:
>
>By child window I mean embedding the front panel of a .vi within another
>.vis front panel.
>>From: "John Smith"
>>I'm trying to find the best implementation of child windows in LabVIEW.
>>Any suggestions?
>>-John
Now, as we all know you cannot create child windows in LabVIEW using VI server. But of coarse he's the guru and he must know, right? Wrong!
Strangely enough, he used to contribute on the Developers Zone @ ni.com but for some reason everyone kept giving him a bad rating. He was doing this on the DevZone for a while and complained to no end about people giving him poor ratings on his answers. He even went so far as to complain to NI and get the negative ratings removed... The reason why you get bad ratings is because you give bad advice. In the Developer Zone you get to be at the top of the list if you post a lot. Quantity not quality gets you to the top?
Now, I don't mind someone who is a zealot about LabVIEW, heck I am (who else would make a weblog about LabVIEW), but he just answers every single thread for the hell of it. It's not easy posting replies to info-LabVIEW. When you post you have to make sure you understand the question and if not ask for clarification. You should also try to post a response that covers several solution options (if possible) and outlines the issues to watch for along the way. The above is just an exmple of his numerous emails that I and others consider "noise".
He has a website, from here you can deduce that the only reason he's posting is to attract some attention and marketing points towards himself. Hey, go visit my website indicated at the bottom of my emal! So he tries to post as many replies as he can. The best way to market yourself is with what you say or publish. All I put under my email is my name and if people want to visit my site all they have to do is look at my email domain and prefix it with the "www"...

Posted by Michael Aivaliotis at 11:29 PM | Comments (0)

Hey, I read my LV

Hey, I read my LV Beta newslist...
I was at a customers on-site today. Tired...

Posted by Michael Aivaliotis at 12:16 AM | Comments (0)

I loathe LabVIEW Guru...

I loathe LabVIEW Guru...

Posted by Michael Aivaliotis at 12:15 AM | Comments (0)

People have this scaling objects

People have this scaling objects on the panels issue all wrong. You don't scale ALL your objects, just 1 or 2. I honestly don't see what the obsession is with this issue of scaling the actual objects to match the resolution. Why would you want your buttons or your fonts to get bigger? Customers want to see more stuff on the screen so they go to a higher resolution. You reward them by filling up the spaces with larger buttons, bigger decorations and bigger fonts, thanks a lot. My frustration in the past has been file dialog boxes or lists of items with multiple columns. There was never a way to resize the window to see more data, more information. I couldn't care less about the font size or button size. Right now I run on a 1280x1024 desktop. Wether I run 800x600, 1024x768 or my current 1280x1024, Windows leaves all my objects the same size but I get more desktop space to work with. The same I believe is true for Apple systems.
Greg Mckascle:
> The typical behavior is to choose a few objects, typically the largest
> objects in the panel and have those adapt to the new window size.
> This control may be a graph, in which case the size taken by the scales,
> cursors and buttons around the graph are normally held fixed, and
> the plotting area grows. If the major area is a table, the table grows
> to show more cells. If the major area is a list or a tree,
> they give access to more cells. I love using dialogs like these that
> grow, and thankfully, many UIs on OSX and XP are moving
> in this direction, but I also know that they are considerably harder
> to implement. Thus far, I can't think of any of them short of magnifying
> utilities that just make the fonts larger or make the pixels larger. If
> they do have a capability, to change the fonts and object sizes, they
> usually choose to do this with a zoom ring at the top of the panel,
> such as is done in the office products, in web browsers, PDF viewers, etc.
> There are apps like PowerPoint, that when they resize the slide preview,
> they grow the fonts, but the rest of the window objects do not resize,
> and so I put them in the resize one object category.
I agree.
One under-utilized feature is the lock objects and group objects tool. I agree that now you can scale only one object, but a caveat is that you must lock and group all other objects surrounding the resizing object or else they move around during re-sizing of the panel and they never fall back to their original position. Also a tip: If you want to get around the resize 1 object limitation just group multiple objects together and then select the "scale object with panel". This will allow you to do things like resize two graphs that are side by side with each other while keeping everything else the same.
We should realize that most applications are programmed for 640x480 base and then they plan for the panel scaling upwards. So in LabVIEW the 640x480 would be considered the "min. panel size" option in vi properties. This is important because if you resize your panel down below the base designed resolution then LabVIEW squishes all objects past each other.
Having said all this we must not just look at this as a LabVIEW issue only. I've downloaded many shareware utilities and non- "mainstream" apps that have a total disregard for their own panel sizing and desktop resolution.

Posted by Michael Aivaliotis at 11:21 PM | Comments (0)

It seems that developers are

It seems that developers are more concerned with lcoking up their software than developing a mviable product. I'd rather spend precious resources trying to sell more product and applications than on software security. I'm not sure of the size of the companies that are commenting on info-LabVIEW but I assume they're not the size of Microsoft, which has a team of hundreds of people that have as an only goal to stop piracy. However they seem to have the same mentality... It's interesting to see the two extremes battling it out on info-LabVIEW. The openg camp (expose it to everyone), and the EXE camp (keep it all hidden).

Posted by Michael Aivaliotis at 01:06 AM | Comments (0)

The latest discussion wave on

The latest discussion wave on info-LabVIEW is about software security. Well, it is a well known fact that you can see your VI names and connector panes for a built executable in LabVIEW. Some feel this means LV is in general less secure than other programming languages. Well, I think it is just a matter of how valuable and how popular your application is. Hackers will crack commercial off-the-shelf packages because there is a huge audience for it. How many copies of an application written in LV will you sell Mr. Systems Integrator?

Posted by Michael Aivaliotis at 01:01 AM | Comments (0)

I feel guilty. Why? I

I feel guilty. Why? I haven't been working with my LabVIEW beta in a while. I contributed to the beta program for a while then I tappered off. Some of the new features kinda turned me off. Can't discuss them, or can I?

Posted by Michael Aivaliotis at 12:54 AM | Comments (0)

Have you ever started working

Have you ever started working on some LabVIEW code and slowly get side tracked into becoming a janitor instead? A LabVIEW wiring and VI janitor? Yup, streighten wires here, create sub-VI's there. Next thing you know you've re-written half the code. This is the challenge when hiring new LabVIEW developers, when to draw the line (or wire). You just have to say, hey - rewrite this entire section please, it's not up to standards.
I am such a control freak!

Posted by Michael Aivaliotis at 10:45 PM | Comments (0)

I hate flat code. Flat

I hate flat code. Flat meaning no sub-VI's. It looks messy, it is difficult to debug, it prevents multiple developers on one project, it hinders code reuse. Ahhh, to be able to decouple the front panel from the diagram, that is pure delight. You notice things like this when you open up other people's code. I had to do this today. The offender will remain unnamed, perhaps in a future post...
Don't create sub-vi's for sub-vi's sake, please. Try to bundle a specific functionality and God forbid, don't embed your globals into a subVI. The first level of sub-VI's are usually found on the diagram of a user-interface. This is the front line. The modularity of your code depends on what your application does, this needs to be defined. How will you break apart your functionality so it is easier to test and debug.

Posted by Michael Aivaliotis at 10:39 PM | Comments (0)

Today was an interesting discovery

Today was an interesting discovery that it sometimes is better to use a for loop than a while loop. I replaced a while loop with a for loop and I got 100 times speed improvement, WOW!. In order to acomplish the behaviour of the while loop, I cased out the code after a certain condition.

Posted by Michael Aivaliotis at 03:28 PM | Comments (0)

This weblog will chronicle my

This weblog will chronicle my ups and downs in the wonderful world of LabVIEW. Why? you might ask, well why not? Anyway, what I really want to accomplish is to help other poor souls who may be stuck on some problem that I may have already solved... how generous eh? Also even though I love the language, I also hate it. It's a love hate relationship so when I get upset I need to vent, voila!

Posted by Michael Aivaliotis at 03:24 PM | Comments (0)