Hi Gianni, I had a quick look on your example of integration Uniface-Gnuplot. I saw that the technic you use is an export of the data by filedump + construction of a command file forGnuplot. In real, what we would like to reach , is a much more direct and simple integration (with R routines in our cases) , avoiding to have to extract on disc the files. (according the situations for us , the size data files can be important. So that the graphics could change really dynamically and as fluidly as possible. I am looking (without success until now) a solution using R Dcom server to integrate with uniface. Another way of investigation , could be with the widget HTML5 ... Anyway, until now we don't have find a satisfactory solution. If you have any ideas or advices ? Best regards Daniel

cabero said ... I saw that the technic you use is an export of the data by filedump + construction of a command file forGnuplot. ...  

YES, one of my prerequisites was to use a self-contained Uniface service to get back a chart; my front-end is passing to the Uniface service some data and attributes and is getting back the chart content or a reference to the file containing the chart. At service level data is dumped together with a gnuplot script, then gnuplot is doing the magic building the chart PNG file which is loaded and passed back as already described.

cabero said ... In real, what we would like to reach , is a much more direct and simple integration (with R routines in our cases) , avoiding to have to extract on disc the files. (according the situations for us , the size data files can be important). So that the graphics could change really dynamically and as fluidly as possible. I am looking (without success until now) a solution using R Dcom server to integrate with uniface. ... 

I've initially also considered the option you describe but the pre-requisite regarding a self-contained service as well as the gnuplot structure has pushed me into my current solution; I can't comment about R: my experience with it is limited and it is by far lower than my experience with gnuplot. The solution you are thinking about for R is similar to use Excel as server: you dialog with server using simple command and the server is doing what you ask for and then you ask for the chart content. Probably it will require a good amount of system memory (RAM) to work effectively with the expected speed. Talking about speed I am very pleased with my solution on my PC; the base size for all charts is about 1megapixel (1024x1024 or 1280x800 depending from attributes requested) and response time when pushing the "generate" button is almost immediate (less than 0.3sec). I made some test adding a BASESIZE param to change chart dimensions: - with BASESIZE=0.5 (512x512 or 720x480) approximately 0.5megapixels response time = 0.2secs - with BASESIZE=1.0 (1024x1024 or 1280x800) approximately 1megapixels response time = 0.3secs - with BASESIZE=2.0 (2048x2048 or 2560x1600) approximately 4megapixels response time = 0.8secs - with BASESIZE=4.0 (4096x4096 or 5120x3200) approximately 16megapixels response time = 1.7secs My gotfeel: not too bad!

cabero said ... Another way of investigation , could be with the widget HTML5 ... ... 

I've also checked HTML5 option following some email exchanged with Uli Merkel (thanks Uli for your small example!); the limit I've found using the HTML5 widget is that the widget is not initialized in a Uniface service; being a Uniface service one of my prerequisites I did not go further. I am still interested now to know if anyone is able to use HTML5 widget in a Uniface service and which tecnique is used to implement it. Thanks anyhow for your attention to this chart solution. Best Regards, Gianni P.S. I hope to have enough time to document it with a short video as soon as possible...it was a goal for christmas time...but, ehm...It's gone!