RP:Lock Control/Unlock Control no longer work as they did in 7.1.

[pbailey]

I need to control access to remote panels programmaticly. In LabVIEW 7.1.1 I was able to pass strings via VIServer to a CaseHandler VI running in the local application space which would issue the Remote Panel Lock and Unlock methods. After converting the CaseHandler to LabVIEW 8.2 these methods no longer work, even if I run the VI directly.

Are these methods expected to work in 8.2, are there any work arounds?

Thanks

Phil Bailey

[Rudi_N]

Phil:

LabVIEW is always backward compatible and I am curious to find out why those methods do not work in LabVIEW 8.2. Do you mind posting the methods that do not work in LabVIEW 8.2?

Regards,

Rudi N.

[pbailey]

Rudi,

thanks for your interest. I have attached a zip file with two versions of my test case:

From the readme file:

Included are two versions of a subset of a Case Handler sub VI that I use in

my application. The cases included are mostly for controlling user access to 

VI's launched via VIServer calls from a .Net WebServices application.

...

The original subVI was scaled down and converted to a standalone VI  using

LabVIEW 8.2. A copy of that VI was then saved to 8.0 and finally to 7.1.12f.

Thanks,

Phil Bailey

[Rudi_N]

Phil:

I was unable to run your program as it is missing "Build URL.vi". Please let me know where I can get that VI.

Thanks,

Rudi N.

[pbailey]

Rudi,

BuildURL is part of the InternetrToolkit, or Enterprise Toolkit of later versions.

I am sending copies of the files that do not depend on the VI, since it is only used by the appStatus case.

Phil Bailey

[Rudi_N]

Phil:

Thank you very much for posting the revised version of your VI. Unfortunately, I still have not been able to test your VI, here are the steps that I followed after reading your readme file:

1. I launched LabVIEW 7.1 and enable access to the WebServer (using HTTP port 81)
2. Opened Test_CaseHandler_71.vi
3. Manually launched C:\Program Files\LabVIEW 7.1\examples\apps\tankmntr.llb\Tank Simulation.vi
4. Copied "Tank Simulation.html" into C:\Program Files\National Instruments\LabVIEW 7.1\www
5. Opened Tank Simulation.html using IE and Firefox.

Firefox could not find the required plugin and IE returned the following: "Invalid Server IP address".
Please let me know what else I need to do to reproduce this.

Regards,

Rudi N.

[CodePeasant]

Worked with Kenn in tech support about this issue in October 2006.  We actually used a modified RemotePanelMethods-Server.vi in 8.2 and proved that the implementation of both RP.Lock Control and RP.Unlock Control of the vi class was not working.  Good to see that others are finding the same.  When will we have this functionality again????  Here is the modified server vi.  Note that Remote Panel Server will not actually serve panels while the project explorer is running so you'll want to open the RemotePanelMethods-Server.vi itself.  This vi works with the RemotePanelMethods-Client.vi.  I know of no work-arounds and am waiting with baited breath for the fix to this egregious (look it up) oversight.  Bait and switch I'd say.......I'm just a little sour about this issue, but if I was worried about it in October, I am now in dire need of this functionality!!!

[pbailey]

K3nt,

Did you get any indication that the bug would be fixed or a tracking number for resolving the RemotePanel Lock/Unlock problem.

I also really need a solution, my current work around is that I close the connection to the user, not a pretty picture, as the VI frame goes to white. Shoud we try again to get some support.

[CodePeasant]

Phil,

Last word I received was that they had told the development team.  I am sure NI will include the fix in the next release, but aside from that, I have no indication that NI will distribute an update.  I do have a tracking number and I attempted to contact the support group today only to find that they were out of the office due to the inclement weather occuring in Austin.  I will try again tomorrow, and the next day ad finitum until I get the issue resolved. 

My workaround was the same as yours, not clean and entierly unacceptable, especially when considering that the description of these functions in the help docs was written with the desired functionality in mind. It taunts the programmer by describing the functionality that the programmer needs, only to supremely dissapoint the programmer who, after debugging the entire software project, finds that the error lies beyond his grasp! 

I had to really convince them that this was really not working.  I am surprised that I haven't received word back on the resolution.  I then looked at the status of the service request and someone has marked it as "presumed resolved".  I will update you on the status via this thread.  We WILL get to the bottom of this!  Or, perhaps are we demanding too much of an API?  Programming with the functionality in mind and then expecting that functionality to actually work...

K3nt

[CodePeasant]

1/19/07:

Still no fix.  If there was going to be a fix made, it wouldn't be released until either a new version of LabVIEW or with a patch of LabVIEW.  No expected time of release.  Two options: make do without until fix is released, or develop in 7.1.

I'd better go find my LabVIEW 7.1 disks...

K3nt