ShaunR

Here's what I would try -- this process anecdotally has helped me, and could help you as well:

1. Ensure repo is up to date with all latest developments; ensure that you have no outstanding changesets or modifications to the working copy, and your team working in parallel has no outstanding modifications that could cause a conflict in SCC
   
2. Open project
   
3. From root node in project, right-click to "Properties >> Project page >> Mark Existing Items button >> ensure every item from dialogue is 'marked'"
   
4. Save all
   
5. Restart LabVIEW
   
6. From GSW, Clear Compile Object Cache
   
7. Restart LabVIEW
   
8. These sub-steps are performed as one "transaction" within the context of one IDE session:
   1. 
      
   2. Open project
      
   3. Recreate that parent library with the exact same name with your up-to-date repo
      
   4. Drag all your ~20 classes back into the library (i.e., the way it used to be)
      
   5. Mass compile (and perhaps, see lots of "problems")
      
   6. Mass compile once more (and probably, most/all "problems" go away)
      
   7. Drag all 20 classes back outside the library (i.e., the way you want it to be)
      
   8. Mass compile (and perhaps, see lots of "problems")
      
   9. Mass compile once more (and probably, most/all "problems" go away)
      
   10. Restart LabVIEW
       

[*]From GSW, clear compiled object cache

[*]Restart LabVIEW

[*]Open project -- build the EXE -- hopefully, the problem is gone. If so, commit to SCC, with a comment why you just modified 100's or 1000's of VIs

 

 We need a W.T.F smiley!

the problem are the clusters! How can I pass the correct cluster to OpenGs read ini vi? 

Use the OpenG variant config to save the clusters to a normal ini-file then run this on it (you might want a little more error checking).

Split-Ini.vi

Yeah I have that feeling too, it just feels so unnecessary to package the whole RTE with my application. Also, it makes the install process a bit weird as the user has to click through the LV RTE install dialogs. If I could find a way to supress those I would settle for that. This should be possible, I just have no idea how

Edit:

Yes. What Phillip said.

InnoSetup is awesome.

I concur. Make sure you get the GUI which is separate (Inno Setup is the script engine).

Agreed, though it's not inherently secure, rather it offloads the security to how the user handles the key. I'd say it's the most secure way software could handle it, but an uneducated or lazy user could still result in no better security than plain text.

Well. The ant-pedant in me ( ) would qualify that in respect to it is inherently secure at the application boundary. There is no software defence for a post-it note of the password on the monitor. 

 

Whole different subject indeed. Suffice it to say I would appreciate a "secure" data type where buffers are strictly managed and not copied at a whim. I shall not hold my breath...

Copying is not an issue, per se. It is the clearing of the memory locations and I don't know either way if LabVIEw does that. It is, however, swings and roundabouts since the key has to exist at some moment in time, in memory, so it is a case of reducing the persistence so that capturing at exactly the right moment on random off-chance is unlikely (not impossible, just unlikely). Of course. If there is zero cleanup, the keys can still exist for quite some time even after the application has terminated making them much easier to capture (until the OS decides it needs it for something else). So LabVIEW probably doesn't score well on that front. But more generally you get more bang for your buck by defending the edge (application/OS/network/buliding) and reducing the opportunities and attack vectors rather than trying to mitigate aspects that require enormous effort and skill levels to make the attack effective. Saying that. The SQLite API does clear all its keys immediately after use, but that's not a lot of consolation if LabVIEW holds on to the un-hashed password string like a drowning man to a buoy

Probably the best you could hope for is that LabVIEW clears its memory when it exits so then at least an attacker would have to have the software running after you have entered the password. However, if your secret data is so secret that you are worried about determined adversaries getting the keys from memory, it is better that they just don't get to run your software at all (lock the office door).

I was curious when you guys are encrypting files, where do you store the key? I have heard if you open a LV Binary in a hex editor you can relatively easily read string constants, so hardcoding in an encryption key may not be the best idea. In general, I am not worried about this happening as I don't need anything "super secure", but I wanted to get other's opinions/solutions.

It depends who you think your adversary is and what they will have access to. You should never "store" a key, rather let the user enter it - that is the only secure way. So when I'm encrypting a file, I never store the key (well, you could argue it is "stored" in memory, but that is transient and a whole subject in and of itself).

Many apps will store something in a file so that users don't have to keep entering the info. This should never be plain text, rather a hash of the password or the password with other stuff combined (SHA256 or SHA512 are quite common-don't use MD5), but this assumes the adversary will either not have access to that hash or will not be able to hook into the software where the key is used if they do get their hands on it. It's more of a case of "security through obscurity" than "secure".since whilst they may not be able to recover the original plain text directly, they may be able to inject the key, look it up on a public database or use it at some point in the applications process space. When used in this way, the key will usually be the result of not only the password, but the password combined with a salt. This, in essence is just another obscurity layer but means that two pieces of information are now required to reconstitute the original. It will, however, be for naught if they are both stored in the same place (a website, for example will store the hash in the DB, but the salt in a file).

Software is a tricky beast since if a competent  adversary has access to the machine, then all bets are off!.It's just a matter of time, persistence and budget.

Hello ShauR, I have downloaded the labview code but cannot transfer file correctly. I have always been receiving error:

 

code-xCB

source-OBEX Error Sending Filename

 

I can transfer file correctly using default programme on PC but get error using labview code.

 

I use my laptop as bluetooth server and my cell phone MEIZU MX as client(I change to samsung and get the same result as well).

 

I notice there is a completed version on lavag.org/topic/12995-cr-opp-push-file/ but I can not download.

 

I do not know how to fix the problem. Can you help me? Thank you!

oooooh,  that was a long time ago now. I'll see if I can dig it out

Hi All,

 

I have some old code I need to make some changes to, and am not certain what version of LV it is done in. I so not have those old versions installed on my PC, and don't really want to install the wrong version.

 

The .lvproj has <Project Type="Project" LVVersion="10008000"> in it, does anybody know if this is 8.6 or 8.6.1? My suspicion is that is it 8.6.1

 

Thanks

Neil

LV 2010

2013 = 13008000

2012 = 12008000

2011 = 11008000

2010 = 10008000

2009 =  9008000

If you have VI Server on both sides, you can avoid polling, at least in your code.  I do not know if you consider VI Server waiting for incoming connections as polling.

I will look into web sockets.  For some reason, the links in you message just take me back to this LAVA post.  Weird.

Hmm. The quick reply seems to screw things up.

Here they are again:

Websocket demo

Examples

Unfortunately, that won't fix it. The problem is not having app1 (the server) discover app2 (the client). The problem is our network security blocks all connections from a server to a client. So, it is fine for a client to initiate a connection to a server, but the server can never connect back. Apparently this would lead to an insecure network so it is not allowed. (personally, I think this is more due to insecure IT people, but either way it is out of my control).

So, I am trying to think of a way for the client to open a connection, leave it open without polling on it and allow the server to use that connection to send a message to the client at any time. I would love to still use VI Server because it eliminates the need to worry about flattening data, but if that won't work, what is the next best thing?

Websockets were created to resolve this sort of problem since browsers do not allow incoming connections (websockets create a bi-directional TCPIP connection). Some of what you describe is a little confusing to me since you talk about "discovery" and "polling" but that has little to do with TCPIP since you must know the IP address and labview isn't event driven (so must poll).

You can try it and see if websockets do what you need by running the demo on the server and using your browser to .connect ala these examples. When you have installed the Demo on the server, just navigate to the examples website and change the IP address in the example pages for that of your server.

Thanks for the fix!  I wish I had found this thread earlier.  Can anybody create a new build and check it into bit bucket or is that reserved for people on the team?  Can somebody get the fix into a new build?

 

 

I have seen similar behavior.  I can try to replicate it if anybody is interested. What I found was that if GetTypeInfo is being called by two separate application instances they block each other because it's non-reentrant.  I don't think we are going to find a work around for that.  This might be a unique situation that I found because of the multiple application instances aspect but I figured it was worth mentioning.

The fix has already been pushed to bitbucket. The others will review it then, if it's acceptable, drjdpowell will fold in any other changes and build a VIP package for the CR (only he can update the CR).

Answered in the Support thread.

Added Path case to "Variant To JSON.vi" and updated example.

(See this post)

Variant To JSON.vi

Example JSON Variant Tools.vi

I think the default case would be able to handle paths if Variant to JSON used OpenG Format Variant Into String.  Why was this not done?

Because the intention is (was?) to remove OpenG dependencies completely...

It's not a complete replacement, though, is it? I think this algo can fail with certain numbers so you'd have to fall-back to the printf and incur the overhead of running two in series. Maybe those numbers cropping up are statistically insignificant though.

Looks great.

I get the following error when trying to download the free version (after entering details).

Not Acceptable

An appropriate representation of the requested resource /polls/index.php/survey/index could not be found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Actually i can conclude that its better to use TDMS right. 

Wrong. Your specification actually states:

A full featured database system is implemented

TDMS is not a "fully featured" database system.

My supervisor told me not to use the SQL server. Make somthing easy concerning labview itself.

None of this is "easy" in LabVIEW.

1. LabVIEW doesn't support QR codes. There are some threads on this forum for some 3rd party solutions

2. You will not find an "off the shelf" solution as this is a specific requirement that many would outsource - you will have to write it..

3. If you have the Database Connectivity Toolkit - use that (you probably do as you are a student).

4. If you don't have the Database Connectivity Toolkit - use SQLite.

5. You will have to learn SQL.

Check the VI Server: TCP/IP Access permissions.

Yes, there's that. I don't suppose you have a rope to toss down to us trudging through the deep end?

I think the only person that could help is probably AQ.

It's been known for some time that LVOOP takes a long time to compile (I have commented before to those that think hours to compile is acceptable). However. I actively avoid LVOOP so my experience is limited for applications. Some might say I have softened a little since I do on occasion use it for trivial APIs to save connectors. The kind of advice I would proffer would involve converting to classical LabVIEW. I expect that isn't an option for you, though, if your whole architecture is OO..

There was some discussion a while back about mutation history getting very large and bogging down load times. Daklu was moaning about it; I believe. You might try and find it on this forum (I couldn't after a cursory look) and try experimenting with deleting the mutation history (see the conclusion and make sure you have backed everything up) for a class or two and see if things improve. But that's just a wild stab in the dark.

It seems like many people are interested in packed libraries for clean, professional-seeming deployments. While that's all well and good, I'm more interested in if it can do anything to mitigate our pain as developers.

They have identical issues to removing diagrams from VIs. i.e. not cross platform or cross CPU arch.For most developers that create tool-kits, utilities or reusable components that are distributed to other devs; they are not a good choice. If you only have one product and only ever use one OS of a single bitness and that will always be the case then that's fine. - welcome to Labviews version of DLL hell

I personally avoid them like the plague-little upside, huge downside. A LLB is superior IMO.

However. In your case. I can't help but feel the only reason you are considering them is through desperation - to cure the symptom of a much deeper problem.

Can u send me the labview code by dng it? Pl

You already have the code-it is shipped with LabVIEW

Thanks for the replies, I am not sure now if I will be able to get any real use out of it for my application, however I will download the trial as you suggested James and see how it goes.

I've never used "Data Finder" but I just load csv files into a SQLite DB. The SQLite API for LabVIEW has a VI to do this for you, but you can do it yourself and once in there, it just boils down to how you want to view the info using queries.

I want the histogram plot to be in the form of the bell shaped curve..tried many things.. but the plot isnt similar.. need ur help

Yes. See the "Noise Statistics.vi" or "Probability Density Function Estimation.vi" in the LabVIEW example Finder.

Search the labview examples for "Histogram"

Project Probe is not only "NOT on the LabVIEW Tools Network", it's not on LAVA or ni.com either.  From the OP: "I'm looking for great free or paid tools [...]"  Tease.

If there is some tool or product you or your company is working on

Just a bit slow, that's all