Loading ...
Sorry, an error occurred while loading the content.

772Re: Hooking

Expand Messages
  • pkaluski
    Feb 14, 2005
      Hi,
      Can you place the zip file with the source code in the files section?

      -Piotr

      --- In perlguitest@yahoogroups.com, "Maricel Ciupitu"
      <maricel.ciupitu@c...> wrote:
      >
      >
      > Hi,
      >
      > Before 1.49 I have to read some data from ListView32 control. So I
      made
      > a dll which uses VirtualAllocEx to read data from the control. Then
      from
      > perl with Win32api call this dll. I attach the source code for dll
      if
      > need it.
      >
      > -----Original Message-----
      > From: pkaluski [mailto:pkaluski@p...]
      > Sent: Monday, February 14, 2005 11:37 AM
      > To: perlguitest@yahoogroups.com
      > Subject: [perlguitest] Re: Hooking
      >
      >
      >
      >
      > --- In perlguitest@yahoogroups.com, "Dennis K. Paulsen"
      > <ctrondlpaulsden@y...> wrote:
      > >
      > >
      > > In the latest CVS builds of Win32::GuiTest/GuiTest.xs, the windows
      > > hook (WH_CALLWNDPROC) is *part* of the puzzle we use, so that we
      > can
      > > interface with various 32bit custom controls, marshall data back
      from
      > > these controls, etc...
      > >
      > > For example, with a ListView32 control we can't simply just issue
      a
      > > call to ListView_GetItemText() to read an item's text, because of
      the
      > > process boundary limiation, you'll normally end up getting an
      access
      > > violation because your accessing data outside of the processes
      address
      >
      > > space...
      > >
      > > Regards,
      > > D
      > >
      >
      > Dennis,
      > If I understand you correctly, hooking solution (in Win32::GuiTest)
      > works as follows:
      > For each control related operation (like getting ListView32
      contents)
      > a hook is set, so the actual list processing is run in address
      space
      > of the process which hosts this control.
      > This solution is correct (it is used by Richter in his book) but I
      > think it brings some maintainability problems. Expanding
      > Win32::GuiTest for handling new controls would reguire changes
      in .xs
      > file and recompilation.
      > I believe I have found more flexible solution. Have a look:
      > http://www.mathimagics.com/TechNote001.html, "Cross-process
      buffers"
      > section. The full example with the code can be found here:
      > http://www.visualbasicforum.com/showthread.php?t=38276
      >
      > In short, instead of hooking, the solution uses VirtualAllocEx
      > function. This function allocates memory is other process's address
      > space. So what you do is this: you allocate memory in address space
      > of a process, which hosts a control. You get pointer to this
      memory.
      > Then, you call Send/PostMessage passing this pointer. Control will
      > respond writting to proper address space.
      > If we manage to create a consistent interface to this
      functionality,
      > we will deliver a mechanism to handle new controls without writing
      > any new C code.
      >
      > -Piotr
      >
      > PS: What is WM_LV_GETTEXT, WM_LV_SELBYTEXT and so on in HookProc?
      > Both google and MSDN did not return anything.
      >
      >
      >
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
      >
      > Prezentul mesaj si orice fisier atasat constituie informatie
      > confidentiala si este proprietatea exclusiva a MobiFon S.A..
      Mesajul se
      > adreseaza numai persoanei fizice sau juridice mentionata ca
      destinatara,
      > precum si persoanelor autorizate sa-l primeasca. In cazul in care nu
      > sunteti destinatarul vizat sau persoana autorizata sa primiti acest
      > mesaj , va aducem la cunostinta ca dezvaluirea, copierea,
      distribuirea
      > sau initierea unor actiuni pe baza prezentei informatii sunt strict
      > interzise si atrag raspunderea dvs. civila si penala. Daca ati
      primit
      > acest mesaj dintr-o eroare, va rugam sa ne anuntati imediat si sa-l
      > stergeti apoi din sistemul dvs.
      > Nu putem garanta ca transmisia acestui mesaj este securizata sau
      fara
      > erori.
      >
      >
      > This message and any files or documents attached are classified as
      > MobiFon SA confidential and Propietary Information. It is intended
      only
      > for the individual or entity named and others authorized to receive
      it.
      > If you are not the intended recipient or authorized to receive it,
      you
      > are hereby notified that any disclosure, copying, distribution or
      taking
      > any action in reliance on the contents of this information is
      strictly
      > prohibited and may be unlawful. If you have received this
      communication
      > in error, please notify us immediately then delete it from your
      > system.Please also note that transmission cannot be guaranteed to be
      > secure or error-free.
      >
      >
      > [Non-text portions of this message have been removed]
    • Show all 14 messages in this topic