Installed application works fine for administrators, not for users - LV7.1.1

[Bandit]

Hi,

Someone must have posted this before, but I can't find it anywhere after much searching of the knowlege base and user forums. Feel free to point me in the right direction...

I have an application that loads and plays a wav file, and applies a filter while playing it back. The user may select the filter being used from the control panel. Filtering is done in1/8 second chunks, so changes in the filter appear instantanious.

I'm using LabView 7.1.1  (i.e. 7.1 with the 7.1.1 maintainence release applied). Filters have been created with the Digital Filter Design tool in the Signal Processing toolset.

I have created an installer using the application builder in LabVIEW. The runtime engine is included in the installation, as are the filter files.

Once installed on a target machine the application works fine for anyone logged on with administrator rights/privileges. For anyone with user or guest privileges the filter either doesn't re-load or isn't applied to the wav file regardless of the user's efforts on the control panel.

The audio file is however loading and playing back.

This problem is seen on W2k, WinXP Pro SP1 and Win XP Pro SP2. I can't comment on other O/S, that's all I have available to test on. 

This is tricky to debug, as in the installed application you can't view or step through the source code.

Your ideas and observations much appreciated.

Bandit

[Bandit]

One more thing - the disk file system on the target machines is NTFS, and an operator with user privileges does have read access to the filter files.

Bandit

[GerdW]

Hello Bandit,

that should be the solution: 'users don't have read access'!

Make sure the users get read access, either by setting the privileges for the folder or by installing your app to a folder, where users have unlimited access rights.
That's always a problem, when installing an app to 'C:Program Files\' (where WinOS is checking for restrictive access rights). I tell 'my' users to install their apps to different folders like 'Docs and Settings' or even better different partitions...

Added:
You can put a subvi in your app which shows the error cluster if there is an error... This way you can at least check what went wrong!

Message Edited by GerdW on 03-30-2006 03:28 PM

[Bandit]

Thanks for the reply GerdW.

A little playing around shows that the filter files aren't being read from disk. I had wired an error LED connected to the output of the vi for loading the dfd filter, as you don't get a full error cluster from it. However, I had forgotten that I had hidden it on the front panel! (It's a while since I coded this). Once it was shown it was aparent that the filter wasn't loaded. Guess my error handling could be better at this point, but I'm in the middle of version 2 of this application so I'll try and do better.

Anyhow, all works OK if the user is promoted to power user (on Win2K). Privileges looks more complex on WinXP but it's besides the point - in real life I can't dictate this to my users, security considerations state they must be plain old users.

So my best solution is to make the sub folder with the filters more accessible to them - don't know how to do this yet, but I'll try. It is a folder that is created by the installer, and my next version will be ported into LabVIEW 8 so perhaps that helps me.

Fallback solution is to move the filters out from C:\programs, but I'd rather keep them where they are if I can.

Anyhow, top answer GerW, I'll post this and rate you accordingly.

Bandit.

[SachaE]

Hi,

  I realise this one is from the CVI forums, however, since it uses the system exec call, you should be able to try it in LabVIEW to change the permissions.

http://forums.ni.com/ni/board/message?board.id=180&message.id=21795&query.id=31940#M21795

Hope that helps

Thanks

Sacha Emery
National Instruments (UK)

[Bandit]

You're right Sacha, it takes almost no time to rate an answer. Only 4* for you, as the info is interesting and relevant, but in this instance I wanted to stick with read only access. These filter files are an integral part of my application, and I certainly don't want users changing them .

A little further investigation has provided the ideal fix for my needs. Burrowing down into the Read DFD coefficients.vi provided in the signal processing toolset I found the files are opened for read & write. The mode isn't actually wired, so read & write is selected as it's the default. As Windows only allows read access in this location to those with user privileges the files won't open. 

I now have a modified version of Read DFD coefficients.vi that has the files opened for read only (this has to be done in 2 places).  I have tested this on Win2k and XP SP2, and it works exactly as I require. This is different to the user in your other thread Sacha, as they specifically want everyone to be able to write to their files.  

Perhaps it's a question for the LV developers - should the Read DFD coefficients.vi be changed to only give read access? (assuming it hasn't been changed already in V8). I'm in no place to assess the impact on other users. As the .vi is only a read function, which opens the file, reads the coefficients and closes the file again I can't see how it would be a problem though - the write access isn't required.

Thanks to all for their help on this. Problem solved, and I'm a happy bunny .  (Thinks - what about some bunny smilies on the forum?)

Bandit

[JeffBoettcher]

Good work debugging that!  I'm not familiar with the API for the Signal Processing Toolkit, but that sounds like a bug to me.  If the function is exclusively for reading (as its name implies) that access mode should be wired with read.  If not, I'd think the access mode should be bubbled up to whatever the top-level API VIs are.  I have filed a CAR (3VU6A41W) for the developers of this toolkit to remedy this.

Message Edited by Jeff B on 03-31-2006 07:26 AM