Qt-interest Archive, January 2008
Troubles getting access to the widgets in different processes
Pages: Prev | 1 | 2 | Next
Message 1 in thread
Hi all:First, sorry my "poor" english !!! XD
I have two apps:
- app1: it calls app2 using a QProcess object.
- app2: application with lot of widgets.
I need get access to app2 widgets through QProcess object.
Might be possible?
I think other way to do it is open a binary made with Qt4 (app2) as a new
window (child widget) from app1.
Can I open (using Qt 4.2) a Qt4 binary app as a new window (QDialog,
QMainWindow, ...) in my own app? Can I send events to a specific widget?
Thanks!!
--
[ signature omitted ]
Message 2 in thread
Hi,
I can try to suggest you something:
1 - use DBUS to communicate between two qt apps. Here you'll need to add
to the logic a set of "messages" that do what you need.
2 - if you have the QProcess, you can use this as a DBUS replacement,
but again you need to messages to go back and forth.
3 - make the app1 to support plugins, and then the app2 will be
implemented as a plugin for app1. Here when it is loaded it will be in
the same address space as the app1, and you can access any
pointers(widgets) directly.
| pedro mateo || wrote:
> Hi all:
> First, sorry my "poor" english !!! XD
>
> I have two apps:
> - app1: it calls app2 using a QProcess object.
> - app2: application with lot of widgets.
>
> I need get access to app2 widgets through QProcess object.
> Might be possible?
>
> I think other way to do it is open a binary made with Qt4 (app2) as a
> new window (child widget) from app1.
> Can I open (using Qt 4.2) a Qt4 binary app as a new window (QDialog,
> QMainWindow, ...) in my own app? Can I send events to a specific widget?
>
>
> Thanks!!
>
> --
> Pedro Luis Mateo Navarro || pedrolmn@xxxxxxxxx
> <mailto:pedrolmn@xxxxxxxxx> _ pedromateo@xxxxxxxxx
> <mailto:pedromateo@xxxxxxxxx>
> > _phone: (+34) 626 14 29 33 or (+34) 968 39 82 58
> > _web: www.pedromana.com <http://www.pedromana.com>
> > _msn: pedrolmn@xxxxxxxxxxx <mailto:pedrolmn@xxxxxxxxxxx>
--
[ signature omitted ]
Message 3 in thread
In Qt 4.4, you can find a class called QSharedMemory that you can use between
processes.
Bo.
On mandag den 14. Januar 2008, | pedro mateo || wrote:
> Hi all:First, sorry my "poor" english !!! XD
>
> I have two apps:
> - app1: it calls app2 using a QProcess object.
> - app2: application with lot of widgets.
>
> I need get access to app2 widgets through QProcess object.
> Might be possible?
>
> I think other way to do it is open a binary made with Qt4 (app2) as a new
> window (child widget) from app1.
> Can I open (using Qt 4.2) a Qt4 binary app as a new window (QDialog,
> QMainWindow, ...) in my own app? Can I send events to a specific widget?
>
>
> Thanks!!
--
[ signature omitted ]
Message 4 in thread
| pedro mateo || wrote:
> Hi all:First, sorry my "poor" english !!! XD
>
> I have two apps:
> - app1: it calls app2 using a QProcess object.
> - app2: application with lot of widgets.
>
> I need get access to app2 widgets through QProcess object.
> Might be possible?
Not without a lot of work on your part. In general, you can't
access anything at all in another process, regardless of whether
it is implemented using Qt or not.
One way to do this would be to implement some kind of signal/slot
IPC object, which talks to a remote process via some form of IPC
(TCP, UDP, shared mem, whatever) and which receives suitably packaged-up
signal messages from the IPC side, unmarshals them, and emits them
as Qt signals to any connected local widgets (and of course, it
would marshal up incoming signals, and dispatch them to the IPC
interface).
--
[ signature omitted ]
Message 5 in thread
Hi all again!!
I forgot a very important restriction: app2 doesn't know what app1 is doing,
app2 therefore can not do anything to communicate with app1.
I don't know how to explain it better, but what I pretend is something like
to get app2's "qApp() pointer" from app1 context.
Thanks!!!
On Jan 14, 2008 3:09 PM, Stephen Collyer <scollyer@xxxxxxxxxxxxxxxx> wrote:
> | pedro mateo || wrote:
> > Hi all:First, sorry my "poor" english !!! XD
> >
> > I have two apps:
> > - app1: it calls app2 using a QProcess object.
> > - app2: application with lot of widgets.
> >
> > I need get access to app2 widgets through QProcess object.
> > Might be possible?
>
> Not without a lot of work on your part. In general, you can't
> access anything at all in another process, regardless of whether
> it is implemented using Qt or not.
>
> One way to do this would be to implement some kind of signal/slot
> IPC object, which talks to a remote process via some form of IPC
> (TCP, UDP, shared mem, whatever) and which receives suitably packaged-up
> signal messages from the IPC side, unmarshals them, and emits them
> as Qt signals to any connected local widgets (and of course, it
> would marshal up incoming signals, and dispatch them to the IPC
> interface).
>
> --
> Regards
>
> Steve Collyer
> Netspinner Ltd
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 6 in thread
pedro mateo wrote:
> I don't know how to explain it better, but what I pretend is
> something like to get app2's "qApp() pointer" from app1 context.
thats not possible. sorry.
the closest thing to what you want is a plugin (as an example, have a
look at plugins for the Qt designer)
Cheers,
Peter
--
[ signature omitted ]
Message 7 in thread
| pedro mateo || wrote:
> Hi all again!!
>
> I forgot a very important restriction: app2 doesn't know what app1 is
> doing, app2 therefore can not do anything to communicate with app1.
>
> I don't know how to explain it better, but what I pretend is something
> like to get app2's "qApp() pointer" from app1 context.
>
> Thanks!!!
>
Even if you were able to get app2's qApp pointer into app1, trying to
dereference it would cause app1 to crash. One application cannot access
the memory of another application. This also means that using shared
memory is difficult. You can put a pointer into shared memory, but if
another application tries to use that pointer, it will crash.
--
[ signature omitted ]
Message 8 in thread
hi:
On Jan 15, 2008 2:10 PM, John McClurkin <jwm@xxxxxxxxxxx> wrote:
> | pedro mateo || wrote:
> > Hi all again!!
> >
> > I forgot a very important restriction: app2 doesn't know what app1 is
> > doing, app2 therefore can not do anything to communicate with app1.
> >
> > I don't know how to explain it better, but what I pretend is something
> > like to get app2's "qApp() pointer" from app1 context.
> >
> > Thanks!!!
> >
> Even if you were able to get app2's qApp pointer into app1, trying to
> dereference it would cause app1 to crash. One application cannot access
> the memory of another application. This also means that using shared
> memory is difficult. You can put a pointer into shared memory, but if
> another application tries to use that pointer, it will crash.
ok, I know it;
but what I pretend is to launch app2 from app1, keeping both at the same
memory space.
then, I think my program won't crash, but I dont know how to do it.
lot of thanks!!.
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 9 in thread
I can still insist on:
- plugin aproach, or
- make all the functionality that you want in only one app - there goes
all the logic you need. Call it "my-all-doing-app".
then make two copies of it: "app1" and "app2".
At lunch it checks for its name and if app1 then do some stuff only, if
app2 the another.
Or you can run the "my-all-doing-app" with different command line
parameters, that will instruct what to do next.
If none of the above works, then it may be the time to reconsider the
design of what you're doing ?
| pedro mateo || wrote:
>
> ok, I know it;
> but what I pretend is to launch app2 from app1, keeping both at the
> same memory space.
> then, I think my program won't crash, but I dont know how to do it.
--
[ signature omitted ]
Message 10 in thread
| pedro mateo || wrote:
> ok, I know it;
> but what I pretend is to launch app2 from app1, keeping both at the same
> memory space.
> then, I think my program won't crash, but I dont know how to do it.
This is impossible. You can't access the memory space of one process
from another. Each process sees a memory space starting from address 0
and going up to some system dependent value (2GB, say). Each process
owns its memory space, and will use the same addresses for different
purposes.
You can *share* part of the memory space between two processes,
but that's somewhat different.
There is no way for one process to use the address of a widget
that was created in another process; even if you could find out
what the address is, you can't call methods on it.
It may help if you explain why you think you need to access the
widgets in another process then maybe someone can suggest an
alternative approach.
However, if you're looking for a way to manipulate the widgets in an
unmodified process (i.e. one to which you haven't added special code)
then you are out of luck.
--
[ signature omitted ]
Message 11 in thread
hi!
I am trying to simulate "human interaction" (click, double click, keypress,
...) sending events (mousepress, mouserelease,...) from app1 logic to app2
widgets.
I know Kexecutor (www.kdab.net) can do, but I don't know if kexecutor use
events or any script language.
cheers!!!
On Jan 15, 2008 4:39 PM, Stephen Collyer <scollyer@xxxxxxxxxxxxxxxx> wrote:
> | pedro mateo || wrote:
>
> > ok, I know it;
> > but what I pretend is to launch app2 from app1, keeping both at the same
> > memory space.
> > then, I think my program won't crash, but I dont know how to do it.
>
> This is impossible. You can't access the memory space of one process
> from another. Each process sees a memory space starting from address 0
> and going up to some system dependent value (2GB, say). Each process
> owns its memory space, and will use the same addresses for different
> purposes.
>
> You can *share* part of the memory space between two processes,
> but that's somewhat different.
>
> There is no way for one process to use the address of a widget
> that was created in another process; even if you could find out
> what the address is, you can't call methods on it.
>
> It may help if you explain why you think you need to access the
> widgets in another process then maybe someone can suggest an
> alternative approach.
>
> However, if you're looking for a way to manipulate the widgets in an
> unmodified process (i.e. one to which you haven't added special code)
> then you are out of luck.
>
> --
> Regards
>
> Steve Collyer
> Netspinner Ltd
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 12 in thread
| pedro mateo || wrote:
> hi!
>
> I am trying to simulate "human interaction" (click, double click, keypress,
> ...) sending events (mousepress, mouserelease,...) from app1 logic to app2
> widgets.
> I know Kexecutor (www.kdab.net) can do, but I don't know if kexecutor use
> events or any script language.
>
I notice that the sales info says:
> KD Executor has two very important advantages over generic recording tools:
>
> 1. The tool is platform-independent, you can record a script on Linux, and reuse it for all the other platforms Qt supports, and vice versa.
> 2. The demonstration capability is build into your program, this makes it impossible for dishonest customers to throw away the demo part and simply use your program.
which leads me to believe that they compile code into the
application to be tested i.e. that this tool cannot operate
on an unmodified executable, which is rather different from
what you're trying to do.
--
[ signature omitted ]
Message 13 in thread
On Jan 15, 2008 11:03 AM, Stephen Collyer <scollyer@xxxxxxxxxxxxxxxx> wrote:
> | pedro mateo || wrote:
> > hi!
> >
> > I am trying to simulate "human interaction" (click, double click, keypress,
> > ...) sending events (mousepress, mouserelease,...) from app1 logic to app2
> > widgets.
> > I know Kexecutor (www.kdab.net) can do, but I don't know if kexecutor use
> > events or any script language.
> >
>
> I notice that the sales info says:
>
> > KD Executor has two very important advantages over generic recording tools:
> >
> > 1. The tool is platform-independent, you can record a script on Linux, and reuse it for all the other platforms Qt supports, and vice versa.
> > 2. The demonstration capability is build into your program, this makes it impossible for dishonest customers to throw away the demo part and simply use your program.
>
> which leads me to believe that they compile code into the
> application to be tested i.e. that this tool cannot operate
> on an unmodified executable, which is rather different from
> what you're trying to do.
As I understand it, KD Executor does its work by wrapping the Qt
libraries so it doesn't require modifying the tested program.
--
[ signature omitted ]
Message 14 in thread
Andrew Medico wrote:
>> I notice that the sales info says:
>>
>>> KD Executor has two very important advantages over generic recording tools:
>>>
>>> 1. The tool is platform-independent, you can record a script on Linux, and reuse it for all the other platforms Qt supports, and vice versa.
>>> 2. The demonstration capability is build into your program, this makes it impossible for dishonest customers to throw away the demo part and simply use your program.
>> which leads me to believe that they compile code into the
>> application to be tested i.e. that this tool cannot operate
>> on an unmodified executable, which is rather different from
>> what you're trying to do.
>
> As I understand it, KD Executor does its work by wrapping the Qt
> libraries so it doesn't require modifying the tested program.
I assume you mean that they wrap the dynamic libraries somehow ?
If so, then that contradicts their claim 2. since it would then
be trivial for "dishonest customers to throw away the demo part"
merely by installing the unwrapped libraries.
Anyway, I'm not at all sure that this helps the OP - I assume
that KD Executor merely injects appropriate window and keyboard
events, which is a long way from the original requirement (if I
understood it properly - maybe I didn't).
--
[ signature omitted ]
Message 15 in thread
hi:
I think I cuold solve this problem using LD_PRELOAD to preloading my library
and replacing some calls.
Then I could create a server object with a TCP connection (or use standard
in/out from QProcess) and get/provide what I want.
Anyone knows something about LD_PRELOAD?
Thanks!"!!
On Jan 15, 2008 8:59 PM, Andrew Medico <a.medico@xxxxxxxxx> wrote:
> On Jan 15, 2008 11:03 AM, Stephen Collyer <scollyer@xxxxxxxxxxxxxxxx>
> wrote:
> > | pedro mateo || wrote:
> > > hi!
> > >
> > > I am trying to simulate "human interaction" (click, double click,
> keypress,
> > > ...) sending events (mousepress, mouserelease,...) from app1 logic to
> app2
> > > widgets.
> > > I know Kexecutor (www.kdab.net) can do, but I don't know if kexecutor
> use
> > > events or any script language.
> > >
> >
> > I notice that the sales info says:
> >
> > > KD Executor has two very important advantages over generic recording
> tools:
> > >
> > > 1. The tool is platform-independent, you can record a script on
> Linux, and reuse it for all the other platforms Qt supports, and vice versa.
> > > 2. The demonstration capability is build into your program, this
> makes it impossible for dishonest customers to throw away the demo part and
> simply use your program.
> >
> > which leads me to believe that they compile code into the
> > application to be tested i.e. that this tool cannot operate
> > on an unmodified executable, which is rather different from
> > what you're trying to do.
>
> As I understand it, KD Executor does its work by wrapping the Qt
> libraries so it doesn't require modifying the tested program.
>
> --
> Andrew Medico <a.medico@xxxxxxxxx>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Pages: Prev | 1 | 2 | Next
