Val Brown

QUOTE (Ton @ Sep 7 2008, 11:05 PM)

Val has the 'http://www.joelonsoftware.com/articles/fog0000000007.html' rel='nofollow' target="_blank">Not Invented Here' syndrome (which is sometime good, sometimes bad).

Ton

I think you might be meaning to say "Not Invented Here or by NI".

QUOTE (PaulG. @ Sep 3 2008, 11:02 AM)

That's probably what I'll end up doing. It was fine this morning, but just before I started to build my application I start getting the error again. Argggggghhhh!!!!

Re: your above post -- do you mean that you upgraded to 8.5.1 and that didn't make any difference?

QUOTE (hfettig @ Sep 3 2008, 04:28 AM)

As you can see from the screen shot, there is a way to use splitter bars on tab controls. However, it is not a direct way. In this case the tab control is displaying an XControl. The XControl has on its facade an XY-Graph and a Multicolumn list box, which are separated by a splitter bar. Works nicely but is probably not practical for most applications.

http://lavag.org/old_files/monthly_09_2008/post-1022-1220441275.png' target="_blank">

I do agree that a simpler support for this would be nice.

I also agree that it would be a great feature to add to LV. Has this been submitted directly to LV? I know that SOMEONE (or several someones) here on LAVA just might work for NI and could see that the suggestion goes to the right place, but I also think someone posted a link FOR that "right place" that the rest of us could use for just this purpose. Anybody know what that link was?

QUOTE (Omar Mussa @ Sep 2 2008, 09:17 AM)

The EasyXML licensing terms are 1 license per developer. We do not have any limits on distribution on number of development machines, number of computers, or number of applications or anything that should feel restrictive to the developer. EasyXML is not open source, if you have a technical issue or feature request please use the http://forums.jkisoft.com/index.php?showforum=29' rel='nofollow' target="_blank">JKISoft EasyXML discussion forum and let us know!

Thanks for making that clarification re: licensing and FWIW I think that's a great way to do it.

QUOTE (Ton @ Sep 1 2008, 11:59 AM)

This post is a try to group several project-related wish-list items into one discussion.

Based on recent discussion (1, 2), I felt there are some things missing to make the project the super-duper LabVIEW IDE enhancement.

The things that are currently lacking (IMHO)

• Set a description for a virtual folder
  This allows you to group VIs under a folder that has a better description than the name of the folder
  
• Setting 'Conditional Disable settings' in the build-properties
  
• Better Build-tools
  • The possibility to set the version of an executable and an installer in one location
    
  • Have dynamic built location (builds\executable\%version%)
    
  • Have the possibility to edit the GUID of an installer
    

  [*]Update the SCC settings when they are edited from within LabVIEW code

  [*]Allow extending of the context menu-items of project items

  [*]Copy build settings from one project to another

Share your thoughts, fill in the poll and respond, make the project perfect.

Ton

I think all of these ideas are right on target. I also like the idea of extending the graphical nature of the Project by allowing for icons for items. A conditional build/edit build feature would be nice: eg if the build breaks, open up the "offending" VI, dependancy or whatever (even dynamically called VIs) pointing to the "problem" much like happens when searching the items in Error View.

QUOTE (jlokanis @ Aug 31 2008, 03:46 PM)

FWIW, the Database Connectivity Toolkit is just a wrapper around ADO.NET. And not a very good one at that. It is extremely slow when working with large record sets.

If you truely want to be native, then write your own DB VIs calling ADO.NET yourself. If you use some of the tricks from Brian Tyler's old blog, you can get a 10x+ speed improvement.

-John

Yes, it is but it's a wrapper that's being maintained by a company, not just "some folks" who might, or might not, get around to it when something happens, and goes wrong. I'm much more interested in reliability and maintainability than speed -- for THAT part of what I do -- as I've got those functions all arranged to happen "off line" in non-time critical ways.

I don't remember off the top how it was resolved. I really have to look back over my archived code to find out how because what I remember is that I submitted the SR, interacted with the AE, got workarounds/solutions and applied them. It was a while ago at this point and I just no longer keep all of those details in my head any longer. Whatever the workaround/solution was, I no longer had the problems with variants with the DCT.

QUOTE (Yair @ Aug 30 2008, 11:39 AM)

I didn't say anything about my experience, so you can't really have the opposite opinion. I've used 7.0 almost exclusively for the past 5 years and was refering to issues I saw others have or only ran across occasionally. Did the issue you resolve have anything to do with saving variants to a DB when upgrading from pre-8.0 to 8.x? If not, then it's not really relevant to the example I cited.

In any case, you should note that I'm not saying anything about the level of support you get from NI, just that in some cases they don't have a solution for you either and if you look through NI's known issues documents you will find some issues with no known workarounds.

I guess I'm still a bit confused about what you're saying. What I understood from you was that you prefer open source because you "can fix it yourself" as opposed to relying on NI and that you were reporting on experiences that you knew about where others -- or you?? -- had encountered problems that NI couldn't resolve and, therefore, you prefer open source. That doesn't make much sense to me as, unless it's a primitive (which is uneditable for everyone), you can always "fix it yourself" in LV or ask others in the community for what they've done to fix, work around, etc whatever you encounter. In any event, in the end, we're all dependent on what NI provides -- certainly in the case of primitives -- and the rest we can always "fix" or adapt ourselves if it's in a VI. If it's a primitive (not something that can be edited directly in LV) then we're all equally "stuck" with whatever NI does regardless of our commitments to open source. If it's anything else, we can modify it, again whether we're committed to open source or not. After all, there was a time when there wasn't a three button dialog and even now that there is one, there's a thread here using that for a coding challenge to improve it. Before the NI version came out I found it a real nightmare to use the third party workarounds that I found. Each was different and didn't play well with the others. At least with the NI version we now have a shared version that is "official" and standard.

Having been through the early Unix and C wars (never mind Pascal, etc), I really don't want to have to continue to play the "keep up with all the versions" game. I do understand that for others that's a perfectly wonderful way to go and the VIPM package in particular seems like a great platform for just that purpose. For me, it's overkill and itself another interface that I would have to learn and maintain. So my perspective may very well be unique here but I do think it's valid, at least for me and perhaps others in my situation.

Yes, I had the exact same problem with variants and the DCT, while moving some of my code through the transition to 8x.

QUOTE (Yair @ Aug 29 2008, 04:44 AM)

That's a good one. NI's release schdules are usually in at least six months cycles and even then there is no guarantee for your problem to be fixed in the next release. I'm not saying that NI doesn't resolve the issues or offers workarounds, just that it's not guaranteed to do it and relying on it is potentially dangerous. At least in open source (and some of NI's code also falls under that category) you have the option of fixing some problems yourself.

A couple of examples that spring to mind:

1. You mentioned the DB toolkit. The DB toolkit relied on a certain behavior of variants when flattening them to be saved to a binary field. In LV 8.0, NI changed the internal structure of variants and this broke, because that use case wasn't tested. This might have been fixed in the new version of the DB toolkit which came out with 8.6, but I never ran into this personally, so I don't know.
   
2. Before LV 7.1, you could control the properties of a caption without any problems. Since 7.1 you had to manually make the caption visible once before it would be created. If you didn't do that, the code which worked for years would now be broken. Did NI fix that? No. It was decided and you had to modify your own code.
   

M experience has been precisely the opposite of you, and certainly so in re: to the DB Toolkit. Working with an AE (I'm on platinum support) we resolved the issue. I addressed it again with the advent of 8.5 and issue with Vista. With some third party tools I was told by the developer, essentially "what you see is what you get". I don't use captions so I have no experience with them.

Yes, the release schedules NOW are pretty predictable -- I've been using LV since v4x so that has improved over the years -- but the support has been and continues to be good and, ultimately, definitive. My experience with open source groups -- of various products -- has been far, far less supportive. I know that's probably blasphemous here but that's how it is.

QUOTE (jed @ Aug 29 2008, 09:40 AM)

Yes, I did AND I got the workaround from an AE, which has been working in my code since then. It STILL works with 8.6 even though I had thought it was "killed" with an earlier 8x release. I've now, finally, moved on to replace that code but not because it doesn't work -- it STILL works, just as it was written for LV 5x. I've replaced it because I know have some new drivers for some older devices (came from the manufacturer of those devices) so it was time to move on.

BTW, I believe that the fix to maintain the legacy serial i/o functions is described in a thread here on LAVA, if that info would be useful at this time.

QUOTE (Jim Kring @ Aug 28 2008, 07:34 PM)

Hi Val,

When you say that you "need to stay with as much native LV as possible", does that mean that you don't use VIs and only primitive functions? Nearly all the OpenG VIs are written in "native LV" (a.k.a., "Pure G"), with the exception of the zip library that makes a call into a DLL.

I'm not trying to make light of your requirements, but to understand your environment and use cases.

Thanks,

-Jim

Hi Jim,

Perhaps I should clarify a bit more what I mean by "native LV". Yes, I use VIs but I use VIs -- as far as possible -- that either I have created or that come for NI directly in their official releases. This way I know that, if there is some problem at some point with a VI no longer working as expected, NI will address it. So I use the Database Connectivity Toolkit instead of just using ADO/DAO or LabSQL, etc because I know, if the functionality isn't there with an update of LV or for whatever reason, it will be addressed. In the past I've made use of several "suites" that were made available by others -- some open source some not -- and then there was a problem when LV updates and the suite from a third party wasn't updated, etc. I'm still working with zlib and the blowfish implementation of encrypt/decrypt because, at that time, it was the most accessible tool available; however, now it's a bit of an albatross. I'd like to get rid of it but probably won't do much about it until after my current pending distro release.

val

I should also add that I've been a bit put-off in the past by all of the confusion around copyright and such as it applies to different third party and/or open source products. Since I distribute a built EXE to end users and I want to be consistent, clear and legal in my use of various tools, it's been a bit challenging to figure out how to include ALL of the various different, and sometimes conflicting, copyright notices needed if using 3rd party additions.

QUOTE (jlokanis @ Aug 28 2008, 06:25 PM)

This example is strictly standard LV code. No add-ons of any kind were used.

The example is written in LV8.5. I don't have older versions so I cannot down-rev it if you do not have 8.5. I would avoid .NET in 8.2 anyways since there were significant bugs.

That said, I use OpenG in many places in my apps and strongly recommend other use it too.

OK, thanks for the clarification. I'll look at it now. I don't use OpenG -- NOT because I don't think it's good. As I've said elsewhere, it's a wonderful set of tools which I have also recommended to others. It's just that, in my environment, I need to stay with as much native LV as possible.

val

QUOTE (Omar Mussa @ Aug 28 2008, 03:32 PM)

I'm not sure what 'this' means... I assume you mean the JKI EasyXML Toolkit because obviously the NI code does not depend on OpenG (and likely never will). The JKI EasyXML toolkit depends on the following OpenG packages:

oglib_string

oglib_lvdata

oglib_error

oglib_array

No, actually I meant the Code Repository example from the top of this thread: viz,

DEMO_XML_File_Read.zip ( 136.39K )

Does that "it" use an OpenG or is it only native LV?

QUOTE (jlokanis @ Aug 25 2008, 04:05 PM)

Here is an example of how to read an XML file, extract attributes of elements and also validate it against a schema.

I use this to read user-editable configuration files for my project. By using XML with a schema, I can control the format of the file and verify that it adheres to this format when reading it. This allows me to abort application startup with a meaningful error message if someone makes an invalid edit to the configuration file.

This is also a good primer on how to read XML files using .NET calls. I hope you find this useful.

I also suggest you read some of the tutorials on the net about XML and XSD (schema) to understand how to create and edit your own files. In addition, I recommend XMLSpy by Altova for working with XML and XSD files.

-John

http://lavag.org/old_files/post-2411-1219705387.zip'>Download File:post-2411-1219705387.zip

Does this make use of any OpenG code or is it all native LV?

QUOTE (TobyD @ Aug 27 2008, 04:16 PM)

I'm curious what people think of the Automatic error handling options in LabVIEW. Is this something you leave enabled? Do you disable it? Why?

http://lavag.org/old_files/monthly_08_2008/post-8758-1219878956.png' target="_blank">

I disable it and wire through Error in and Error out clusters manually.

QUOTE (Darren @ Aug 27 2008, 11:37 AM)

<..>You'll notice that almost all of my shortcuts can be typed with the left hand only (I'm right handed). Thus, if I type a shortcut, and then click in the VI to dismiss Quick Drop and automatically drop the item, I never have to move my left hand from the keyboard, and I never have to move my right hand from the mouse. *This* is how I am able to program so fast with Quick Drop.

OK, now that sounds useful.

QUOTE (rolfk @ Aug 25 2008, 11:42 PM)

Ohh and don't even attempt to try and run a timed loop. It's internal mechanisme was last time I checked tightly coupled with drivers that go directly into the Windows kernel. Wine is an application level API translation software. They do not have nor want to try to provide a kernel level translation layer so far.

Rolf Kalbermatter

Precisely. Fusion is getting pretty good but it still has some limitations when it comes to i/o and drivers.

QUOTE (rolfk @ Aug 25 2008, 11:30 PM)

I haven't tried it recently! But CrossOver is basically based on Wine (with some extra hacks to make it sometimes work better for standard applications like the unavoidable Office Suites from an unnamed company in Redmond and in the case of Mac of course for the unmatched apps like iTunes etc.)

LabVIEW 5 and 6 did run already many years ago (around 2000 or so) fairly well on Wine of that time. But its installer was also a lot lighter and less problematic than the super duper multi mega monster installer of recent LabVIEW versions. And also before LabVIEW 7 you could in the worst case just copy an entire LabVIEW tree over to the Wine system and run it from there without the need for an installation.

On the other hand Codeweaver has done tremendous work on Wine to support the MSI installer technology and it is currently in a state that allows a lot of applications to install with little or no problems.

So I think you have a realistic chance to get LabVIEW itself running on Wine and/or Crossover. Wine versus Crossover is here likely to make no difference since CodeWeavers has LabVIEW for obvious reasons not on their radar, although I think installation of Wine on a Mac is still supposed to be quite a bit of a hassle whereas CrossOver would seem to give you a smooth installation experience.

Of course things like IO drivers are most probably not gonna work at all. This likely is even true for VISA and slightly possibly even TCP/IP. NI-DAQ and just about any other NI-something would be a waste of time to even attempt to try.

I stopped with dabbling with LabVIEW on Wine after LabVIEW for Linux got available. It simply made not much sense anymore to deal with difficulties and some strange screen drawing artefacts when LabVIEW was run on Wine.

Rolf Kalbermatter

Yes, I would agree with this. I haven't investigated v8.6 but there were considerable problems with early release versions of 8 that I did try. And, yes, the biggest problem were i/o and driver related.

QUOTE (Norm Kirchner @ Aug 25 2008, 12:50 PM)

I can tell you this.... Jeff Kodosky refers to the language as G.

I'm sticking with him.

Yes, I understand that, however, he's also a Mac user and wants to have all of the same functionality in the Mac version as in the Windows version (and yes the other platforms as well). At this point, I'm not holding my breath. :headbang:

QUOTE (Yair @ Aug 25 2008, 10:41 AM)

I won't go into this discussion either, but just to comment on this point: http://forums.lavag.org/A-Blast-From-The-Past-t729.html' target="_blank">This article from 1986 makes repeated reference to the language behind LV as "G". I have the "G programming reference manual" (for LV and BridgeVIEW) from 1999, which also refers to the language as G, so at least NI thought about it that way. It's possible that this was stopped due to copyright issues.

It is my understanding as well FWIW that NI stopped the reference to "G" because of copyright infringement concerns, however those were generated/recognized within NI.

QUOTE (Ton @ Aug 23 2008, 01:06 AM)

An error cluster represents an error if the boolean is True.

In other cases it is considered a Warning, though GPIB functions have some codes that mean 'Successfully applied'

Ton

Hence, it's a "warning" about something potentially not being 100% in alignment with the overall code or purpose of the code.

QUOTE (jcarmody @ Aug 23 2008, 02:43 AM)

There's an interesting article on the NI Developers Zone about this - http://zone.ni.com/devzone/cda/tut/p/id/5313

"If tool A and tool B can be used for a certain set of tasks, but tool B has more functionality that makes it useful for additional tasks, which tool is really the more general one? This is precisely where we are with LabVIEW. LabVIEW¹s suitability for measurement and automation applications comes about not because its fundamental programming abilities are restricted in some way, but because they are enhanced and extended."

Yes, that's clear. And at the risk of further inflaming the discussion, these kinds of issues are really "religious identity" issues. They are never decided based on rational inquiry but on the basis of the lived commitments of those who engage in the discussions/arguments. Those who grew up in the "house of holy text-based" programming will continue to see that kind of programming environment as what's "real and true" and will validate the rest of their experience based on that history. Seen from that perspective it is almost inevitable that LV will be seen as being a "toy", only good for "tests and measurements", only good for "laboratories" or whatever other rationalization can be "hung on" the LV IDE. The ability to integrate virtually any other text-based language, the ability to code in a consistent manner across deployed environments, the ability to not HAVE TO acquire numerous third party libraries to "link in", etc, etc will all be dismissed, if they are even acknowledged. Add in the fact of how easy it is for someone to actually program in LV -- esp those who have NO background in CS -- and you've got all the ingredients for a "religious war" over who is the "real" programmer" and what is a "real" programming language.

Yes, I agree that from a pure CS perspective, LV is not a complete language. G is not entirely written in G, etc. Yes, of course, those are valid points and perhaps at some point in the future that will change. NI will choose to devote the considerable resources it would take to implement ALL of G/LV in G itself. But, even if that were to happen, it would make NO difference to the religious identity issue. If anything, it would only serve to intensify it because it would take away one of the seemingly "rational" reasons to say that LV isn't "complete".

Yes, NI could potentially make a difference by renaming the language but that's just another version of the same identity issue. BASIC never was "basic" -- it never way "All Purpose". It had limitations and, when it become "Visual" it was still not "All Purpose". Now people refer to it as VB and don't even consider those nuances -- esp those who "grew up" in that environment and are now committed to it simply by virtue of their lived history of use of it. LabVIEW could simply become known as "LV" (perhaps for "Less Verbiage"??) but those renaming issues STILL won't address the core issue.

It's all about what programmers "grew up" with and what they were educated to believe that "real" programmers do, and what a "real" programming language is. LV subverts most of that and does it in a way that allows non-CSers to literally "compete" with the end products produced by CSers. That's the final and fundamental aspect of the "religious identity" issue. LV by its very nature, ease of use, and general abilities, seems to "take away" and/or "diminish" the uniqueness of having a CS background. It isn't arcane but intuitive -- unless you've been taught to believe that malloc() etc is "intuitive". It's easy to use -- I taught my 8 year old to program in it and she could produce -- back then -- running programs after very simple instruction. And all of that makes LV appear to be a serious threat to those who have lived commitments to their hard earned identities as "real text-based programmers".

OK, end of rant and now it's time for me to step of that soapbox...

QUOTE (Tom Bress @ Aug 21 2008, 08:46 AM)

I typically take the offending non-error-propagating native function and wrap it in a sub-vi wrapper that has error cluster propagation, like the OpenG Wait function. Then I can use it in the future as well without resorting to sequence structures.

I favor this approach as well. In prior versions (LV 5 maybe 6) there were rumors of extra overhead when using this kind of process instead of sequence structures but I don't think the overhead of a sub-vi call is an issue any longer.

QUOTE (Ton @ Aug 19 2008, 10:14 AM)

Good idea, maybe something like 'Code development tools'?

Any other namse?

I am willing to filter the last few months or so for threads that should apply to such a forum.

Ton

That would be phenomenally helpful to get this started.

QUOTE (Neville D @ Aug 19 2008, 10:30 AM)

LVdebugKeys=True

Thanks for posting that. I think it's clearest to actually provide the specific response/answer when it's known.

QUOTE (Omar Mussa @ Aug 19 2008, 08:23 AM)

That's one way to do it -- but you may end up missing out on something and can lose work.

The whole reason that you get the .r2, .r3 is so that you can choose to resolve the conflict with 'use mine' or 'use theirs'. Also, sometimes its really helpful to be able to tell what the differences are in the conflicted VIs (you can open them with LabVIEW and use their comparison/merge tool). When you are done you can mark the conflict as 'resolved' (I believe this will delete the .r2, .r3 files but not sure). This gives you the power to not lose work by comparing what the differences are in the conflicted files.

Another way to get rid of conflicts is to delete all your local changes (or move them to a temp folder), and do a revert on the folder. That will get you to the latest state (based on the update that gave you a conflict). Now you can copy the files back from temp folder into your source folder and they will appear 'changed' (as opposed to 'conflicted') and you can commit them to your repository.

Thanks for all of the tips.

I'm wondering about whether it would be useful to have a SVN forum on LAVA? A lot of LAVA members seem to use it and, one "gateway" for info about SVN might be a real encouragement and support to those of us who have yet "jumped in" or who have and hit their head on the bottom of the pool.

QUOTE (Neville D @ Aug 19 2008, 08:11 AM)

...There is an ini key that you can add to LabVIEW.ini to enable a bit more info for these sorts of messages to help identify which object is causing the error and whether its a BD or a front panel issue.

Neville.

And that key would be?