I am facing a large decision, to continue developement with labview or to m= ove on to .NET or Delphi. <br>The desire to move comes from the simple fac= t that .NET and Delphi applications 'look' more like windows applications b= oth in appearance and operation. What I am talking about are the menus for= file, edit,printing that we are so used to with such packages as Excel and= the like.<br>I tend to use labview in the following way: write an applica= tion and distribute it to MANY clients running everything from 98 to XP. I= just feel labview is moving away from this sort of application and Nationa= l Instruments is not picking up the ball on making the front end of VIs run= more like windows applications. I have called national instruments and sc= rubbed the web looking for information and have really turned up little. b= efore I just jump off the labview wagon that I have happily been on for 7 y= ears now I would like to hear input from the group.<br>Running 7.1 on WIN20= 00 for development.<br><br>Greg
Greg,<br><br>You will surely get responses on both sides of this issue. Wh= en I first did some LabVIEW consulting about eight years ago, the guy I was= working with was spending an inordinate amount of time trying to make LabV= IEW "look more like a Windows app." At that time, of course, there were no= menus of any kind other than the ones you kludged together yourself with a= ring control and then cursed for not looking very good and for taking up p= rocessing overhead for polling. Also, there was no native checkbox object,= no tree control, etc, etc. I can't recall how extensive the "dialog contr= ols" palette was back then, but it was presumably much emptier than today.<= br><br>My personal opinion is that LabVIEW has been pretty good about intro= ducing features and widgets that make it easier to create Windows-looking a= pps (and Mac-looking apps, and I suppose Linux-looking apps, for that matte= r). However, I haven't done any real VB or VC++ or .NET development in rec= ent years to provide a strong point of reference.<br><br>So, I'm interested= in a little more detail about where you see LabVIEW falling short on the "= looks and feels like a Windows app" front. What exactly is it about the me= nu or printing behavior that doesn't quite cut the mustard? I know this is= a general topic that the developers very actively solicit feedback about, = so I think highly specific comments are best.<br><br>My two cents,<br>John
Well things that come to mind,<br>1. The buttons used in labview do not lo= ok like the buttons used in 'windows type apps' specifically excel.<br>2. = The menu I refer to is the common windows menu that is at the top of intern= et explorer allowing for easy navigation to functions such as save, print a= nd similar.<br>3. Also, take a look at a graph in labview and a graph in E= xcel. Not the same, however a graph in Delphi looks exactly like the one i= n Excel. The labview graph works, but again, the appearance issue. <br><b= r>I know labview is for engineers and the like, being one myself it has bee= n quite useful over the years, but I think National Instruments could cash = in big if they gave it the look of .NET but kept is simple to program. <br= >Applications written in .NET or Delphi are just dressier I guess and that = is where I need to be somehow.<br>An example is, I got the $99 intro versio= n of Delphi and wrote an application that has all the features and appearan= ce of notepad.exe in windows, looks and runs just like it I do not see how= to do the same in labview. Obviously I need to be able to do more than ju= st create a simple text editor, but hopefully you all get the direction I a= m going here.<br><br>Will comment more if needed.
Well, since LabVIEW is cross platform and not strictly Windows, I suspect t= hat you'll always see some differences from apps that depend on the Windows= API. The MAC/Linux/Sun users complain about how Windows centric LabVIEW is= right now with a lot of functions tied to things to ActiveX. Personally, I= think LabVIEW comes pretty close to emulating a Windows look and feel with= some small minor differences. I like that each new version of LabVIEW adds= more and more dialog type controls that have made the differences less not= iceable. With a little bit of work, things can be made better. For example,= the pull-down menus can be changed so that they call the Windows API. For = other things, like loss of Windows 98 support, there's not much you can do = except support an older LabVIEW version. According to what NI has said, Mic= rosoft announced they were dropping support of Win98 and NI decided to foll= ow suit. When Microsoft changed their mind, it was too late to change 7.1 i= n time for it's release. <br><br>Are there some specifics that you don't li= ke about the LabVIEW windows? LabVIEW programmers have done some pretty ama= zing stuff. Maybe you'll find an answer if you say exactly what you need.
Greg Shipley wrote: > Let me be clear, not bagging on LV or NI, just trying to point out > what I am faced with believe me, I do not want to go to .NET.<br><br> Welcome in the club! > A little more specifics.<br><br> > 1. Ability to put graphics on buttons like a printer icon ect.<br> I do this regularly with the custom control editor. > 2. Ability to have text and objects resize correctly between screen > resolutions. I doubt Windows applications do in general much better than what LabVIEW does when scaling one specific control to the screen and moving the rest along. The only possible problem here is that LabVIEW does iteratively calulate the new positions, instead of in relation to the original size, so resizing panels abusively back and forth will introduce some control creep due to rounding errors. Scaling the entire front panel with all its objects including text is simply an almost hopeless thing to do under Windows. Restricting rescaling to one control only (this is in fact what applications like excel do as well) however works quite satisfactorily. > 3. Ability to have printing not affected by screen resolution.<br> Using a PS printer and selecting Postscript output in LabVIEW should fix that problem. But hairline plots will be hairline then and that can be very thin. > 4. Ability to have a menu, button scheme that looks like Outlook and > other applications in the windows world. Do you mean those icons in the menu? I consider this a very questionable UI element but yes LabVIEW does not support this yet. As to those button schemes of Outlook and other Windows applications: They are mostly MS applciations and those features are often not supported by the OS but simply MS specific extensions to their applications. If it is a good idea to try to copy all those elements in every single application seems also questionable to me. > People are used to this and just hard to charge $400 - $1000 for a > software package that does not have that look and feel. Well to be honest I feel it may be more difficult to sell an application for 100$ without those features, than one for 1000$ or more. I'm admittingly working almost always in the range beyond 1000$ and there the latest MS ideas about UI design are usually not very important. Rolf Kalbermatter
Greg,<br><br>It may be that we're assuming an awareness of certain LabVIEW = features that you may not have. So, pardon me if this is all old hat, but = I wanted to make sure to cover them:<br><br>- You can get 90% of the way ho= me, in terms of making the widgets on your VI look standard for your OS, if= you stick to the "Dialog Controls" control palette. If you're not in the = habit of dropping most of your new panel controls from there, you should de= finitely get into that habit, and you may find that you've solved most of y= our problem.<br><br>- The LabVIEW run-time menu is really a great feature t= hat produces fairly standard Windows-looking results. Just in case you're = not intimately familiar with these menus, then make sure to go to Help >> F= ind Examples and check out the menu examples under Building User Interfaces= >> Menus and Toolbars. You are correct that LabVIEW does not currently su= pport adding graphics alongside the choices (I don't think), but you might = notice that not all Windows applications actually do this either. For exam= ple, Internet Explorer (sure the most familiar Windows app of all!) avoids = graphics unless the user selects the Favorites menu.<br><br>Just for kicks,= I wanted to see how well I could mimic an Excel dialog in LabVIEW. I chos= e the Chart Wizard, and I've attached my LabVIEW analog. Just by using the= Dialog Controls, I was able to crank out widgets (tab control, listbox, st= ring indicator, buttons) that look almost perfect (I run XP). The chart-re= lated images in the listbox were a problem, so I had to resort to using the= Tree Control, which permits custom images. I could not make the images le= ft-justify, because the tree control is reserving some space for the tree h= ierarchy lines and collapse/expand elements. It wasn't simple to get custo= m images in there, but I followed the lead of this <a href=3D"http://sine.n= i.com/apps/we/niepd_web_display.DISPLAY_EPD4?p_guid=3DBC79EE820A742645E0340= 80020E74861&p_node=3DDZ52034&p_submitted=3DN&p_rank=3D&p_answer=3D&p_source= =3DExternal" target=3D_blank>Traversing Tree Controls and Setting Custom Sy= mbols</a> example. The chart sub-type choices are just buttons with import= ed images--easy to do in the Control Editor.<br><br>The real difficulty wou= ld be making the thing behave correctly in response to the user's actions--= showing a new set of chart sub-types, ensuring that only one chart sub-type= at a time could be selected, etc. All this would take time and effort tha= t might not be worth it. And indeed, if the most important feature of your= project is to have it look and feel as much like Excel, Outlook, etc, as p= ossible with minimal programming overhead, then you may well be better serv= ed to do the project in some other development environment.<br><br>Another = two cents,<br>John wizard.vi: http://forums.ni.com/attachments/ni/170/104530/1/wizard.vi
Hi guys<br><br>I read through this thread and I think it's very interesting= , that some guys want to have their LV look like MS applications.<br><br>If= I develop a user interface, I just use LV controls and color them with sys= tem-colors. For me it is an advantage that the application does not look li= ke it was a MS product.<br><br>I experienced users who were a little bit mo= re confident about the LV app than about MS apps. Sometimes I develop in Ja= va and there I also made the same experience.<br>I also experienced users w= ho did not just "click around" in the software. In a usual MS app they just= click around if something does not work as they want it to. In my LV apps,= they are more careful and call me if they have a problem (ok my software i= s just used in our company). But I'd rather like a user who calls me, than = a "wild clicking" one who curses about my app, which he seems to be so fami= liar with.<br><br>Although I just develop for windows targets, it's clear t= o me that the user should see that the application is different to windows = and MS at all.<br><br>Thomas
Greg,<br><br>I went through this same decision for my company. All in all = there are a few important things to pass on to you.<br><br>1) For me, time = to market is much faster using LabVIEW than C or C++. There are probably m= any C++ programers who would disagree, but this is my opinion.<br><br>2) We= rely heavily on Ni DAQ, which is by far easiest to impliment in LabVIEW<br= ><br>3) I have found that a LabVIEW program can look virtually identical to= a typical windows program using<br> a) direct call to the WinAPI using th= e call dll function<br> b) Microsoft Active-X controls which can be used f= or almost anything<br> For example, you can embed an Excel graph into = LabVIEW if you don't like the one's available<br> Personally, I think = that LabVIEW's graphs are the one feature that gives it a clear advantage<b= r> c) Third party Active-X controls for features that MS only offers in th= e WinAPI<br> You have to pay for these, but the cost of the controls = is far cheaper than developing them yourself in any language
Greg,<br><br>I went through this same decision for my company. All in all = there are a few important things to pass on to you.<br><br>1) For me, time = to market is much faster using LabVIEW than C or C++. There are probably m= any C++ programers who would disagree, but this is my opinion.<br><br>2) We= rely heavily on Ni DAQ, which is by far easiest to impliment in LabVIEW<br= ><br>3) I have found that a LabVIEW program can look virtually identical to= a typical windows program using<br> a) direct call to the WinAPI using th= e call dll function<br> b) Microsoft Active-X controls which can be used f= or almost anything<br> For example, you can embed an Excel graph into = LabVIEW if you don't like the one's available<br> Personally, I think = that LabVIEW's graphs are the one feature that gives it a clear advantage<b= r> c) Third party Active-X controls for features that MS only offers in th= e WinAPI<br> You have to pay for these, but the cost of the controls = is far cheaper than developing them yourself in any language.<br><br>= The one problem that I have with LabVIEW is that multi-platform development= costs extra. I do not think that I should have to pay 3 times to build my= applications for Windows, Mac, and Linux.