Problem using the File Dialog Box in a Client/Server application

[linus]

I am developping a client-server application using Labview 5.1 . The application on the server acquires data from some instruments and saves it on file, while the application on the clients displayes such acquired data. For doing this I call some routines on the server via the "Open Application vi" (remote connection). All goes well except when I open on the server the "File Dialog Box vi" : in this case the application on the clients is blocked (is blocked the execution of the called vi on the server). Only when
the File Dialog Box on the server is closed, the execution of the called vi on the server starts again.
I need to use the File Dialog Box on the server, but I don' t want to stop at the same time
the clients !!
I need help for resolving such problem.

Many thanks in advance !!!

[waldemar.hersacher]

It seems that the VIs called by the clients are running in the user interface thread.

A call to the file dialog box will call a modal system dialog. So LV can't go on executing VIs in the user interface thread.

One thing you can do is set the execution system of the VIs which will be called by the clients to another system.

Another thing you can do is you can start a VI through VI server which runs in another execution system. In this VI you can preload the called VIs by opening a reference to them.

[linus]

Thak you for your answer.
I have set a different execution system (data acquisition)for the VIs called by the VI server but nothing has changed : the VI actually called is always blocked by the file dialog.

I try your 2nd advice.
Wellcome other suggestions.

Best regards.

linu§

[Andrey_Dmitriev]

Hi!

waldemar.hersacher wrote:
"It seems that the VIs called by the clients are running in the user interface thread.

A call to the file dialog box will call a modal system dialog. So LV can't go on executing VIs in the user interface thread."

Are you sure? I think, that File Dialog, called by LabVIEW File Dialog from Advanced File Functions Palette doesn't blocking any cycles in subVI, which running in UI Thread. Look in my old example (that was prepared for other topic, but may be good for this topic too).

2 linus:
I think, you must a little bit reorganize you application for to do this. You must put your File Dialog into separated cycle. This cycle, of course, will be blocked when File Dialog appear on the screen. But other cy
cle, which responsible for visualization will run continuosly at the same time...

[JeanPierre]

Indeed, having a modal window opened locks "Open VI Reference" function in a local or remote call. IIRC it is also locked when the user uses the menu bar of the VI.

It is quite annoying and I solved this making the server application to have NO user interaction at all. When you need user interaction, make it in a client application. Anyway, if the server runs on a different machine, it is not a good idea to have a client request popup for a user input on the server machine. There is no guarantee that there will be an operator to enter the input.

If you give more information about your architecture, maybe we'll be able to solve your problem in a more specific way.

[linus]

I have find out the same problem also with Printer Setup dialog box.

Best regards.

linus

[linus]

Hi Andrey,
thank you for your answer. But when I try to open the VIs in your attachment it appears an error message :
Resource not found. An error occurred loading .
Labview load error code 8 : Could not load VI's resource. Could it be a different version of Labview ?
My actual version is LV 5.1
In every case could you explain by word what those VIs do ?
Furthermore other things to point out in my application :
- There is a main cycle in the server that manages and visualizes the data and where is inserted the File Dialog.
- There is on the server a 2nd cycle (indipendent from the 1st) that acquire the data from the instruments and save it on file, which is not blocked by the File Dialog.
- The VIs (on the server) called by the clients
are indipendent (different) from the VIs of previous two cycles. These VIs transfer the data to the clients.
These VIs are running in a different execution system (with respect to the other two cycles).

Thank you in advance.

linus

[Andrey_Dmitriev]

These VIs for version 5.1.
I have no found full cycles blocking (except cycle with File Dialog, of course)

[linus]

Hi Jean-Pierre,
thank you for your answer.
My server application is a complete application : you can use it stand-alone. There is a data acquisition process that acquire the data from the instruments an save it on files (this process has no interaction with operator). And there is a user interface that implements visualization and managing of these data (the user can operate on the server in the same way as a client). Furthermore the user can manage (backup, delete, riprist) the files with the data collected.
The client application instead is only used to visualize and manage the data acquired by the server in different locations (other PCs).
I will give you more information about the application if you need.

Thank you in advance.

linus

[JeanPierre]

I have designed a similar application.

I wrote a separate server application that makes data acquisition/storing/server. This app has no user interaction except the front panel showing its current status. It runs 24/7.

I also wrote a client application that takes care of all user interactions for data display and config. Data is retrieved and config is set through requests to the server app.

Splitting your app in server/client parts maybe more or less easy depending of how both parts already communicates in the application. If you use a lot of different communication mechanisms (globals, queues, LV2 globals, etc) you'll have to convert all this to VI Server calls.

This offers a lot of advantages as the client application can be
eventually run from anywhere on the LAN/Internet instead of being run on the machine connected to the instruments. But I think it is already what your actual client application does anyway.

Good luck.