Hi Christoffer,

newinstance supports the /async switch.

There is some info about "communication between components" existing, but I can't remember, where I found it.
I had no time to play with the concepts.

But I think it's worth to look for Sendmessage / Postmessage / ...

Success, Uli

P.S: perhaps someone has REAL experience and likes to share it with us.

Hi,

We do this currently, into both tree widgets and grid widgets. (So painted occurrences would work as well...)

The main issues are that the service has to run on a server (via urouter/userver) and that there is a singnificant limit on the length of the message that can be passed by asynch messages (I think it's 1000 or 4000 chars....)

Hejsan Christoffer,

If you want to do some massive asynch's then the limits in forms are as Firesongkt said. Maybe this would be a good start to do some USP/DSP development!?

Via AJAX you easily can trigger any update synch or asynch (in parallel) to the (web) Interface. The DSP lives it and the USP has even more control on it. If u need some hints on this, let me know :)

Ha det bra,

-GHAN-

Thanks for the hints guys. I'll need to look into the postmessage size-limit, I'm not quite sure if this is really an issue with the current designideas.

The asynch messaging really only need to contain a select count() / lookup at the moment. Fetching / processing the real data could perhaps be done inside the service at a later point or be transacted via lists or xmlstreams.

I'm also going to use these asynch operations with multiple treewidgets, hence I might poke you, FiresongKt, since you seem to have a lot of experience. (I've never built trees before, so, just making those work as intended will be a challenge).

I've also never built anything completely async that runs serverside so I'll most likely return to you guys with more questions later.

GHAN: Building DSP's would be a deam-come-true, both for me and the product - alas, we're not quite there yet (still stuck in a 2-tier "forms only" design). On a side note - I think you're the first swedish-speaking person I've ever found on these forums .. c'ept my co-workers that is - mycket intressant och välkommet :)

... tak skal du ha'! ;)

Now let me tell you, that 2-tier isn't a problem to do the web with uniface- its up to you guys how abstract you want to define it! Just make sure to habe lots of functions deployed in services "och resten" will get a piece'o cake ;) Drop me a mail if you like to.

Hi Christoffer,

a possible way (once developed for async error message storing) is:

at application exec, start a common communication service (ComCom) as a buffer for async information.

- the async processes will "upload" their results to "ComCom" and get back a technical key.
- the postmessage to the calling form just needs to contain the status of the operation plus the "ComCom" access key.
- the calling form can get (and purge) the data from the "ComCom".

Success, Uli

P.S. thanks for your "dITo digest" subscription

Thanks a lot for the feedback.

I'll stay in touch once this project takes of for real in a few weeks or so. It sure seems like this could get very interesting. If I'm lucky our migration to 9.4 will be completed this spring.. so.. perhaaaps I'll be allowed to do some web-work then. I'll keep your offer in mind gahn, tack så mycket.

We already have a "march-hare-message-object" running in our system at the moment that some of our service components use to communicate with forms. Perhaps it's time to expand it's functionallity as you suggest uli, and just let the form poll the message-service for changes at set intervals. This might be easier to implement than having the service communicate with the form directly.

Looking forward to more dITo stuff    (...I'd kill for an eclipse plugin ;) haha)

Hi Christoffer,

spoke with some chaps about "running /async inside the calling uniface process"

They report that they had no success making this work,
even when the docu says nothing again that concept.

They only had success when they used the application server assistance
which raises a need for inter-process communication (or a periodical scan of a DB entry).

If you want to avoid the application server (license),
you can start a second uniface application
which accepts jobs from a database
and return their results.

So there are a couple of options how to do the job.

Success, Uli

Hi Christoffer,

AFAIK, it is possible to execute async components inside your running uniface application.
The "ComCom" construct is based on this as well.

No need for inter-process-information handler (urouter, userver, u.....).

This way, you can just
- activate an operation on the calling form to return the data.
- when the async component has done it's work (no need for postmessage etc.).

Success, Uli

P.S. I discussed this with a friend who is more experienced in the /async side.
Given some time, it may be nice if you can share your experiences with us here.

I'll look into what makes the most sence - running locally or serverside. The whole point is keeping the GUI responsive, not necessarily to distribute cpu-load.

I'll make sure to keep you all posted as the project progresses.