I can see starting a uniface application FROM another one (using spawn) but I'm not so sure about within another application.

What are you trying to achieve?

Yes, with spawn or using the OS signature , I can start an uniface application from another one, but not inside.
Puff, I don´t know exactly; I´m thinking in an application that can execute two uniface application and integrate both in an master application, that controls both, without adding any codeline in children applications.

Regards,Rafa.

Hi Rafa,

what do you mean with "controls both"?

You can have 2 running uniface applications and a Master using IPC (inter process communication)
to send commands to the running applications what to do.

My favourite is the communication via HTTP:

- a listener in your uniface application(s) with differnt portnumbers to handle the requests.

- UHTTP for the messaging.

Uli

Hi Uli,
In my mind i have the idea to create an external uniface application that can integrate two differents application without adding any codeline, using web application i think it´s possible, but in a client/server application i don´t find a solution.

The only solution that i find it´s adding some operations in all components to get and set the information.

My idea it´s make two applications, one it´s a test application, that shows variables, entities, status,... and maybe make some easy automatic test, and the other it´s the master that execute both applications and pass the necessary information.

It´s only an idea, but...

Rafa.

Hi rafa,

that shows variables, entities, status,...  so you plan to create another udbg ? (try to bribe some CPWR insider for the how2).

If you have 2 applications running, each has their own adress space and perhaps global variables, procs etc. they do not like to "share".

So InterProcessCommunication is the way to go. Perhaps it is sufficient to have a non-modal form for all that IPC stuff.

Another option uses SENDKEY messages to simulate user interaction (like the nice old /tfo /tfi feature in uniface CHR mode)

It´s not a real debbug because this tool don´t stop the app and don´t change any value; another matter tell me that the address space it´s the real problem.
I´ll make a little test and if works with IPC or SENDKEY I´ll tell you.

Ty, Rafa.

another pretty simple way just for experiments is communication via file:

a service tries to fileload a specific file (command input) on a regular base (triggered by a UTIMER).

If it's loaded, the file will be emptied immediately using filedump "".

Then the service executes whats written in the file.

I used some kind of "scripting language" separated by = so I can use $idpart and $valuepart

Very BASIC, but a first way for remote control (opening a port listener in a uniface app is more work, i suppose)

Uli

Personally I'd use the urouter functionality via postmessage, which then fires the async trigger. You can then fill in the async trigger of the application start up shell, which will catch the message and then act on it.

All you need then is a datafile somewhere listing the $instancepath:$instancename for the application start up shell and you're away.

Hi Iain,

another way doing the job, but I am not sure what happens if you run multiple apps with the same "name".

My example was developed a couple of years ago to interrupt long lasting batch processes.

We started applications multiple times with different working directories (different clients)
and we needed a method to have some easy control which application to be influenced.
Plus thze option to do this even outside of a uniface application (via a ,bat file)

We had commands like:

close_after_checkpoint (we work with packages to keep memory stress to a minimum)
abort_immediately (causes a rollback for current package processing)

Uli

In order to use it at all, you have to give the app a UST (/ust=MYAPP in the command line). Uniface won't let you start two client apps on the same machine with the same UST, so one uses the ust name in the command line to 'name' the app.
(You can use the same ust on several machines, as the machine IP is part of the $instancepath. )

In order to allow our clients to run more than one copy of the app, we use a batch file to assign a ust which is part windows user name and part random number (so my current UST for my app here is 1.sharp13999)

The telephone book for inter client communication, opening the app registers in the database, and starting a component with on the fly display changing also stores the filters applied so only relevant updates can be sent out.

For inter program communication (from crystal reports to trigger actions in uniface apps) we pass the 'address' in the parameters to the crystal reports.

It's horses for courses really.

Hi Rafa

From the sounds of things what you want is an application that runs for the client and a version of it that runs for the testing team,

If it was me, I would either...

a) add a menu function that pops up an info screen with $fieldname/entname, global variable values etc etc,

b) add a key that fills the message frame with your debug data

b) if there is a common c* header field in all screens... i.e. screen title... to populate it with some debug data if a special keyboard key is pressed, and zoom it.

Cheers

Osie

Running a Uniface application (visually) inside another Uniface application could be very interesting to have when you have a mix of Uniface 8 and 9 applications. I have no idea how to accomplish it, but it would be very interesting.

Yes, an interesting idea indeed. I think it would have to be tricked, because I don't think mouse/keyboard/windows actions of two processes can't be controlled by one. You would need to tightly control size and position of both applications, making the 'inner' one fit into an open area of the 'outer' one, tell Windows to keep the 'inner' one always on top, make sure the inner one has no windows frame, and that kind of thing. It would probably involve some low-level 3GL code, and other windows would probably interfere. But I'm sure something could be achieved that looks visually convincing.