EV_GRID problems

[Jimmy Johnson]

I must have forgotten how to enable right click pick-n-put in my applications.  My EV_ROWS within my EV_GRID contain the object I want to pick.  Information is displayed withing a couple of EV_LABELs within each row.  

So, how do I right click on the label and pick up the object?

BTW, what is with wel_hook.dll?  Must that be included with any distributed executable?

Thanks,

Jimmy J. Johnson

[Jocelyn.Fiat.ES]

You might want to check EV_GRID.*pebble*

You will notice:
        item_pebble_function: detachable FUNCTION [ANY, TUPLE
[detachable EV_GRID_ITEM], ANY]
            -- Returns data to be transported by pick and drop mechanism.
            -- It will be called once each time a pick on the item area
of the grid occurs, the result
            -- will be assigned to `pebble' for the duration of transport.
            -- When a pick occurs on an item, the item itself is passed.
            -- If a pick occurs and no item is present, then Void is passed.

About wel_hook.dll, this is used to handle various mouse hooking.
And it is preferable to include them in the folder as your (UI) executable.
I let other give more precise details about the wel_hook.dll

Hope this helps,
-- Jocelyn


Jimmy Johnson wrote:

> I must have forgotten how to enable right click pick-n-put in my applications.  My EV_ROWS within my EV_GRID contain the object I want to pick.  Information is displayed withing a couple of EV_LABELs within each row.  
>
> So, how do I right click on the label and pick up the object?
>
> BTW, what is with wel_hook.dll?  Must that be included with any distributed executable?
>
> Thanks,
>
> Jimmy J. Johnson
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>  

--
Jocelyn
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  

[rfo]

Hi Jimmy!

Have you heard an answer to the wel_hook.dll question yet?
As soon as I added some pick-and-drop stuff, the error appeared.  I have
resisted fixing it (as it seems to make no functional difference so
far).


     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: [eiffel_software] EV_GRID problems
> From: "Jimmy Johnson" <[hidden email]>
> Date: Sun, September 20, 2009 7:43 pm
> To: [hidden email]
> I must have forgotten how to enable right click pick-n-put in my applications.  My EV_ROWS within my EV_GRID contain the object I want to pick.  Information is displayed withing a couple of EV_LABELs within each row.  
> So, how do I right click on the label and pick up the object?
> BTW, what is with wel_hook.dll?  Must that be included with any distributed executable?
> Thanks,
> Jimmy J. Johnson

[Emmanuel Stapf]

The wel_hook.dll is required for the best pick and drop experience. That is to say a line that appear even when you are not on top of your Windows (or desktop for that matter), and if I'm not mistaken it also prevents the window to raise to the top when starting a pick and drop.

Regards,
Manu

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of [hidden email]
> Sent: Tuesday, September 22, 2009 2:33 PM
> To: [hidden email]
> Subject: RE: [eiffel_software] EV_GRID problems
>
> Hi Jimmy!
>
> Have you heard an answer to the wel_hook.dll question yet?
> As soon as I added some pick-and-drop stuff, the error appeared.  I have
> resisted fixing it (as it seems to make no functional difference so
> far).
>
>
>      R
>
> ==================================================
> Roger F. Osmond
>
>
> > -------- Original Message --------
> > Subject: [eiffel_software] EV_GRID problems
> > From: "Jimmy Johnson" <[hidden email]>
> > Date: Sun, September 20, 2009 7:43 pm
> > To: [hidden email]
> > I must have forgotten how to enable right click pick-n-put in my
> applications.  My EV_ROWS within my EV_GRID contain the object I want to
> pick.  Information is displayed withing a couple of EV_LABELs within each
> row.
> > So, how do I right click on the label and pick up the object?
> > BTW, what is with wel_hook.dll?  Must that be included with any
> distributed executable?
> > Thanks,
> > Jimmy J. Johnson
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[rfo]

Hi Manu!

Thanks for the quick response.
This presents a problem.  I really don't want to get into the business
of distributing DLLs.
In my test app, I get the error on each pick, but it seems to be working
quite reasonably.  Is there a test I should be trying?  Is it possible
to do without and disable the warning message?

Thanks,
     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: RE: [eiffel_software] EV_GRID problems
> From: "Emmanuel Stapf [ES]" <[hidden email]>
> Date: Tue, September 22, 2009 5:51 pm
> To: <[hidden email]>
> The wel_hook.dll is required for the best pick and drop experience. That is to say a line that appear even when you are not on top of your Windows (or desktop for that matter), and if I'm not mistaken it also prevents the window to raise to the top when starting a pick and drop.
> Regards,
> Manu
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On Behalf Of [hidden email]
> > Sent: Tuesday, September 22, 2009 2:33 PM
> > To: [hidden email]
> > Subject: RE: [eiffel_software] EV_GRID problems
> >
> > Hi Jimmy!
> >
> > Have you heard an answer to the wel_hook.dll question yet?
> > As soon as I added some pick-and-drop stuff, the error appeared.  I have
> > resisted fixing it (as it seems to make no functional difference so
> > far).
> >
> >
> >      R
> >
> > ==================================================
> > Roger F. Osmond
> >
> >
> > > -------- Original Message --------
> > > Subject: [eiffel_software] EV_GRID problems
> > > From: "Jimmy Johnson" <[hidden email]>
> > > Date: Sun, September 20, 2009 7:43 pm
> > > To: [hidden email]
> > > I must have forgotten how to enable right click pick-n-put in my
> > applications.  My EV_ROWS within my EV_GRID contain the object I want to
> > pick.  Information is displayed withing a couple of EV_LABELs within each
> > row.
> > > So, how do I right click on the label and pick up the object?
> > > BTW, what is with wel_hook.dll?  Must that be included with any
> > distributed executable?
> > > Thanks,
> > > Jimmy J. Johnson
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >

[Peter Gummer-2]

Roger Osmond wrote:

> This presents a problem.  I really don't want to get into the business
> of distributing DLLs.
> In my test app, I get the error on each pick ...

The solution is easy. Don't use pick and drop in your applications.  
It's not a standard part of the user interface of any operating  
system, so our users would have to re-learn how to use their computers  
if we foist pick-and-drop upon them.

Drag and drop is the standard way to do things. Is wel_hook.dll  
required for drag-and-drop?

- Peter Gummer

[rfo]

Hi Peter!

We'll leave the debate of better vs popular for another time :)
The wel_hook.dll problem exists with D&D too :(

Thanks

     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: Re: [eiffel_software] EV_GRID problems
> From: Peter Gummer <[hidden email]>
> Date: Tue, September 22, 2009 6:38 pm
> To: [hidden email]
> Roger Osmond wrote:
> > This presents a problem.  I really don't want to get into the business
> > of distributing DLLs.
> > In my test app, I get the error on each pick ...
> The solution is easy. Don't use pick and drop in your applications.  
> It's not a standard part of the user interface of any operating  
> system, so our users would have to re-learn how to use their computers  
> if we foist pick-and-drop upon them.
> Drag and drop is the standard way to do things. Is wel_hook.dll  
> required for drag-and-drop?
> - Peter Gummer

[Jimmy Johnson]

Oh rats!  I really wanted to slug it out.

Manu, I think you must copy the dll to the w_code directory?  I know it is not that much trouble but I seem to repeatedly delete the eifgen directory (perhaps a bad habit pattern from earlier versions of EiffelStudio no longer required).  But, is there a way to put the dll in a more perminant directory and have systems pick up on it?

jjj




--- In [hidden email], <rfo@...> wrote:

>
> Hi Peter!
>
> We'll leave the debate of better vs popular for another time :)
> The wel_hook.dll problem exists with D&D too :(
>
> Thanks
>
>      R
>
> ==================================================
> Roger F. Osmond
>
>
> > -------- Original Message --------
> > Subject: Re: [eiffel_software] EV_GRID problems
> > From: Peter Gummer <p-gummer@...>
> > Date: Tue, September 22, 2009 6:38 pm
> > To: [hidden email]
> > Roger Osmond wrote:
> > > This presents a problem.  I really don't want to get into the business
> > > of distributing DLLs.
> > > In my test app, I get the error on each pick ...
> > The solution is easy. Don't use pick and drop in your applications.  
> > It's not a standard part of the user interface of any operating  
> > system, so our users would have to re-learn how to use their computers  
> > if we foist pick-and-drop upon them.
> > Drag and drop is the standard way to do things. Is wel_hook.dll  
> > required for drag-and-drop?
> > - Peter Gummer
>

[Chris Saunders-4]

I'm not certain of this but I think you can copy it to the root directory of
your project.  I have come across this before but don't remember exactly
what I had to do.

Regards
Chris Saunders

----- Original Message -----
From: Jimmy Johnson
To: [hidden email]
Sent: Tuesday, September 22, 2009 9:58 PM
Subject: [eiffel_software] wel_hook.dll ?


  Oh rats! I really wanted to slug it out.

Manu, I think you must copy the dll to the w_code directory? I know it is
not that much trouble but I seem to repeatedly delete the eifgen directory
(perhaps a bad habit pattern from earlier versions of EiffelStudio no longer
required). But, is there a way to put the dll in a more perminant directory
and have systems pick up on it?

jjj

--- In [hidden email], <rfo@...> wrote:

>
> Hi Peter!
>
> We'll leave the debate of better vs popular for another time :)
> The wel_hook.dll problem exists with D&D too :(
>
> Thanks
>
> R
>
> ==================================================
> Roger F. Osmond
>
>
> > -------- Original Message --------
> > Subject: Re: [eiffel_software] EV_GRID problems
> > From: Peter Gummer <p-gummer@...>
> > Date: Tue, September 22, 2009 6:38 pm
> > To: [hidden email]
> > Roger Osmond wrote:
> > > This presents a problem. I really don't want to get into the business
> > > of distributing DLLs.
> > > In my test app, I get the error on each pick ...
> > The solution is easy. Don't use pick and drop in your applications.
> > It's not a standard part of the user interface of any operating
> > system, so our users would have to re-learn how to use their computers
> > if we foist pick-and-drop upon them.
> > Drag and drop is the standard way to do things. Is wel_hook.dll
> > required for drag-and-drop?
> > - Peter Gummer
>

 

[Emmanuel Stapf]

> Manu, I think you must copy the dll to the w_code directory?  I know it
> is not that much trouble but I seem to repeatedly delete the eifgen
> directory (perhaps a bad habit pattern from earlier versions of
> EiffelStudio no longer required).  But, is there a way to put the dll in
> a more perminant directory and have systems pick up on it?

Personally, I've created a directory `c:\bin' and added it to my PATH environment
variable and this is where `wel_hook.dll' is. Of course this only works because it
is my development machine. For deployment, you have to put `wel_hook.dll' next to
your executable.

Regards,
Manu

[rfo]

Hi Manu!

More to the point, the dll must be in your path for it to be found.
If placed 'next to' your executable, it will work only if that place is
the working directory (it often is). The default working directory in
estudio workbench mode is the W_code directory, which is why placing it
there makes it work.

Now, back to the gnarly part.
The reasons for having the function in wel_hook are clear thanks to you
earlier explanation, but my question about the reason for a DLL versus a
static library remain unanswered.  Why is that not an option?


     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: RE: [eiffel_software] wel_hook.dll ?
> From: "Emmanuel Stapf [ES]" <[hidden email]>
> Date: Wed, September 23, 2009 12:29 pm
> To: <[hidden email]>
> > Manu, I think you must copy the dll to the w_code directory?  I know it
> > is not that much trouble but I seem to repeatedly delete the eifgen
> > directory (perhaps a bad habit pattern from earlier versions of
> > EiffelStudio no longer required).  But, is there a way to put the dll in
> > a more perminant directory and have systems pick up on it?
> Personally, I've created a directory `c:\bin' and added it to my PATH environment
> variable and this is where `wel_hook.dll' is. Of course this only works because it
> is my development machine. For deployment, you have to put `wel_hook.dll' next to
> your executable.
> Regards,
> Manu

[Jocelyn.Fiat.ES]

[hidden email] wrote:
> Hi Manu!
>
> More to the point, the dll must be in your path for it to be found.
> If placed 'next to' your executable, it will work only if that place is
> the working directory (it often is). The default working directory in
> estudio workbench mode is the W_code directory, which is why placing it
> there makes it work.
>  
Note that the default working directory when launched by EiffelStudio is
the folder containing the .ecf file.
This is not anymore the W_code since 6.3 (or 6.4)
This change was made to help developer, then no need to copy test file,
or pixmap, or dll in their W_code after each compilation (from scratch).
> Now, back to the gnarly part.
> The reasons for having the function in wel_hook are clear thanks to you
> earlier explanation, but my question about the reason for a DLL versus a
> static library remain unanswered.  Why is that not an option?
>  
As Manu explained, we use the .dll in order to add a mouse (and
keyboard) hook (system-wide hook).
And this has to be done at the system level.
Mainly because the application needs to be able to draw the P&D line
(and also handle the Escape key) *when the mouse cursor is not over the
Eiffel application.

*This is how Windows works using dll.
If ever you know another solution, then please let ISE know.

hope this helps,
Jocelyn

PS: maybe the warning in the console might be annoying.

>
>      R
>
> ==================================================
> Roger F. Osmond
>
>
>  
>> -------- Original Message --------
>> Subject: RE: [eiffel_software] wel_hook.dll ?
>> From: "Emmanuel Stapf [ES]" <[hidden email]>
>> Date: Wed, September 23, 2009 12:29 pm
>> To: <[hidden email]>
>>    
>>> Manu, I think you must copy the dll to the w_code directory?  I know it
>>> is not that much trouble but I seem to repeatedly delete the eifgen
>>> directory (perhaps a bad habit pattern from earlier versions of
>>> EiffelStudio no longer required).  But, is there a way to put the dll in
>>> a more perminant directory and have systems pick up on it?
>>>      
>> Personally, I've created a directory `c:\bin' and added it to my PATH environment
>> variable and this is where `wel_hook.dll' is. Of course this only works because it
>> is my development machine. For deployment, you have to put `wel_hook.dll' next to
>> your executable.
>> Regards,
>> Manu
>>    
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>  

--
Jocelyn
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  

[rfo]

Hi Jocelyn

Thanks for clarifying the working directory point (and for moving it to
the .ecf location; quite helpful).

On the DLL front, perhaps it's my lack of understanding, or I am not
expressing myself adequately.

I accept that the function is necessary.  That is not the issue.

What I do not understand is why that function must reside in a DLL and
not within the static WEL library.

A DLL is essentially the same as a static library except that it is
identified, not linked, at the end of the compilation sequence.  A DLL
is typically chosen because it is needed by multiple clients and because
it is either more convenient or more space-efficient to distribute that
logic separately (rather than embedding it into every possibly client).
It is a question of form, not of function.

As I see it, those advantages are no match for the serious disadvantage
of requiring that we distribute, install, locate and so forth an
additional file for our othewise ordinary Eiffel Vision apps.  It
effectively precludes offering a standalone application, and requires
some form of installation program.  That stinks.

So, I will pose my question one more time.

Why is is not possible to move the logic, currently in wel_hook.dll,
into the wel library?


     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: Re: [eiffel_software] wel_hook.dll ?
> From: "Jocelyn Fiat [ES]" <[hidden email]>
> Date: Fri, September 25, 2009 9:51 am
> To: [hidden email]
> [hidden email] wrote:
> > Hi Manu!
> >
> > More to the point, the dll must be in your path for it to be found.
> > If placed 'next to' your executable, it will work only if that place is
> > the working directory (it often is). The default working directory in
> > estudio workbench mode is the W_code directory, which is why placing it
> > there makes it work.
> >  
> Note that the default working directory when launched by EiffelStudio is
> the folder containing the .ecf file.
> This is not anymore the W_code since 6.3 (or 6.4)
> This change was made to help developer, then no need to copy test file,
> or pixmap, or dll in their W_code after each compilation (from scratch).
> > Now, back to the gnarly part.
> > The reasons for having the function in wel_hook are clear thanks to you
> > earlier explanation, but my question about the reason for a DLL versus a
> > static library remain unanswered.  Why is that not an option?
> >  
> As Manu explained, we use the .dll in order to add a mouse (and
> keyboard) hook (system-wide hook).
> And this has to be done at the system level.
> Mainly because the application needs to be able to draw the P&D line
> (and also handle the Escape key) *when the mouse cursor is not over the
> Eiffel application.
> *This is how Windows works using dll.
> If ever you know another solution, then please let ISE know.
> hope this helps,
> Jocelyn
> PS: maybe the warning in the console might be annoying.
> >
> >      R
> >
> > ==================================================
> > Roger F. Osmond
> >
> >
> >  
> >> -------- Original Message --------
> >> Subject: RE: [eiffel_software] wel_hook.dll ?
> >> From: "Emmanuel Stapf [ES]" <[hidden email]>
> >> Date: Wed, September 23, 2009 12:29 pm
> >> To: <[hidden email]>
> >>    
> >>> Manu, I think you must copy the dll to the w_code directory?  I know it
> >>> is not that much trouble but I seem to repeatedly delete the eifgen
> >>> directory (perhaps a bad habit pattern from earlier versions of
> >>> EiffelStudio no longer required).  But, is there a way to put the dll in
> >>> a more perminant directory and have systems pick up on it?
> >>>      
> >> Personally, I've created a directory `c:\bin' and added it to my PATH environment
> >> variable and this is where `wel_hook.dll' is. Of course this only works because it
> >> is my development machine. For deployment, you have to put `wel_hook.dll' next to
> >> your executable.
> >> Regards,
> >> Manu
> >>    
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >  
> --
> Jocelyn
> ------------------------------------------------------------------------  
> Eiffel Software
> 805-685-1006
> http://www.eiffel.com       
> Customer support: http://support.eiffel.com       
> User group: http://groups.eiffel.com/join       
> ------------------------------------------------------------------------

[Jocelyn.Fiat.ES]

In order to see the effect of the wel_hook.dll
here is a simple way to do

1) Now, open EiffelStudio and load a project.
    Right-Click on a (clickable) class name and move your mouse pointer
out of your EiffelStudio's window.
    You will notice the dotter line goes out of the window, and is still
drawned

2) Now, check in all your folder included in %PATH% , and also the
folder containing ec.exe
    and remove (or rename) all occurrences of wel_hook.dll
    close all your EiffelStudio's instances
    retry 1)

    You will notice your class "icon" and the P&D dotted line stops at
the border of the EiffelStudio's window

So this was to show what the wel_hook.dll is for , useful when you want
to P&D a class from an EiffelStudio's window to another one.

Now, why using a dll?
Simply because this is the way to achieve that with Windows.
I think this is called the system wide hook.
And I think that when EiffelStudio (for instance) is launched, it will
declare this dll as a system hook for the mouse (and I guess for the
keyboard too).
And then the other graphical application will also load this
wel_hook.dll ...

Then, yes Windows needs this to be a DLL, since it will be loaded by
other graphical applications.
For the technical details, I let you google for it.

Does it answer the question?
If not, I will try to find a technical explanation on the web.

-- Jocelyn

> On the DLL front, perhaps it's my lack of understanding, or I am not
> expressing myself adequately.
>
> I accept that the function is necessary.  That is not the issue.
>
> What I do not understand is why that function must reside in a DLL and
> not within the static WEL library.
>
> A DLL is essentially the same as a static library except that it is
> identified, not linked, at the end of the compilation sequence.  A DLL
> is typically chosen because it is needed by multiple clients and because
> it is either more convenient or more space-efficient to distribute that
> logic separately (rather than embedding it into every possibly client).
> It is a question of form, not of function.
>
> As I see it, those advantages are no match for the serious disadvantage
> of requiring that we distribute, install, locate and so forth an
> additional file for our othewise ordinary Eiffel Vision apps.  It
> effectively precludes offering a standalone application, and requires
> some form of installation program.  That stinks.
>
> So, I will pose my question one more time.
>
> Why is is not possible to move the logic, currently in wel_hook.dll,
> into the wel library?
>
>
>      R
>
> ==================================================
> Roger F. Osmond
>
>
>  
>> -------- Original Message --------
>> Subject: Re: [eiffel_software] wel_hook.dll ?
>> From: "Jocelyn Fiat [ES]" <[hidden email]>
>> Date: Fri, September 25, 2009 9:51 am
>> To: [hidden email]
>> [hidden email] wrote:
>>    
>>> Hi Manu!
>>>
>>> More to the point, the dll must be in your path for it to be found.
>>> If placed 'next to' your executable, it will work only if that place is
>>> the working directory (it often is). The default working directory in
>>> estudio workbench mode is the W_code directory, which is why placing it
>>> there makes it work.
>>>  
>>>      
>> Note that the default working directory when launched by EiffelStudio is
>> the folder containing the .ecf file.
>> This is not anymore the W_code since 6.3 (or 6.4)
>> This change was made to help developer, then no need to copy test file,
>> or pixmap, or dll in their W_code after each compilation (from scratch).
>>    
>>> Now, back to the gnarly part.
>>> The reasons for having the function in wel_hook are clear thanks to you
>>> earlier explanation, but my question about the reason for a DLL versus a
>>> static library remain unanswered.  Why is that not an option?
>>>  
>>>      
>> As Manu explained, we use the .dll in order to add a mouse (and
>> keyboard) hook (system-wide hook).
>> And this has to be done at the system level.
>> Mainly because the application needs to be able to draw the P&D line
>> (and also handle the Escape key) *when the mouse cursor is not over the
>> Eiffel application.
>> *This is how Windows works using dll.
>> If ever you know another solution, then please let ISE know.
>> hope this helps,
>> Jocelyn
>> PS: maybe the warning in the console might be annoying.
>>    
>>>      R
>>>
>>> ==================================================
>>> Roger F. Osmond
>>>
>>>
>>>  
>>>      
>>>> -------- Original Message --------
>>>> Subject: RE: [eiffel_software] wel_hook.dll ?
>>>> From: "Emmanuel Stapf [ES]" <[hidden email]>
>>>> Date: Wed, September 23, 2009 12:29 pm
>>>> To: <[hidden email]>
>>>>    
>>>>        
>>>>> Manu, I think you must copy the dll to the w_code directory?  I know it
>>>>> is not that much trouble but I seem to repeatedly delete the eifgen
>>>>> directory (perhaps a bad habit pattern from earlier versions of
>>>>> EiffelStudio no longer required).  But, is there a way to put the dll in
>>>>> a more perminant directory and have systems pick up on it?
>>>>>      
>>>>>          
>>>> Personally, I've created a directory `c:\bin' and added it to my PATH environment
>>>> variable and this is where `wel_hook.dll' is. Of course this only works because it
>>>> is my development machine. For deployment, you have to put `wel_hook.dll' next to
>>>> your executable.
>>>> Regards,
>>>> Manu
>>>>    
>>>>        
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>  
>>>      
>> --
>> Jocelyn
>> ------------------------------------------------------------------------  
>> Eiffel Software
>> 805-685-1006
>> http://www.eiffel.com       
>> Customer support: http://support.eiffel.com       
>> User group: http://groups.eiffel.com/join       
>> ------------------------------------------------------------------------
>>    
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>  

--
Jocelyn
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  

[Jocelyn.Fiat.ES]

A MSDN link for Windows global hook

http://msdn.microsoft.com/en-us/library/ms644960%28VS.85%29.aspx


-- Jocelyn

[rfo]

Hi Jocelyn!

OK, I think I finally understand.  The wel_hook.dll is needed by other
applications to see what the Eiffel application is doing, not by the
Eiffel application itself.  That is why it must be a DLL.

So the conclusion is that it still stinks, but it's not Eiffel's fault!

It would seem that MS, with its legion of developers, would by now
provide a capability-based registration mechanism rather the old
name-based model that requires apps to provide their own DLLs.  It's
soooo 1980s.

Thanks for your help and you patience.


     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: Re: [eiffel_software] wel_hook.dll ?
> From: "Jocelyn Fiat [ES]" <[hidden email]>
> Date: Fri, September 25, 2009 11:19 am
> To: [hidden email]
> In order to see the effect of the wel_hook.dll
> here is a simple way to do
> 1) Now, open EiffelStudio and load a project.
>     Right-Click on a (clickable) class name and move your mouse pointer
> out of your EiffelStudio's window.
>     You will notice the dotter line goes out of the window, and is still
> drawned
> 2) Now, check in all your folder included in %PATH% , and also the
> folder containing ec.exe
>     and remove (or rename) all occurrences of wel_hook.dll
>     close all your EiffelStudio's instances
>     retry 1)
>     You will notice your class "icon" and the P&D dotted line stops at
> the border of the EiffelStudio's window
> So this was to show what the wel_hook.dll is for , useful when you want
> to P&D a class from an EiffelStudio's window to another one.
> Now, why using a dll?
> Simply because this is the way to achieve that with Windows.
> I think this is called the system wide hook.
> And I think that when EiffelStudio (for instance) is launched, it will
> declare this dll as a system hook for the mouse (and I guess for the
> keyboard too).
> And then the other graphical application will also load this
> wel_hook.dll ...
> Then, yes Windows needs this to be a DLL, since it will be loaded by
> other graphical applications.
> For the technical details, I let you google for it.
> Does it answer the question?
> If not, I will try to find a technical explanation on the web.
> -- Jocelyn
> > On the DLL front, perhaps it's my lack of understanding, or I am not
> > expressing myself adequately.
> >
> > I accept that the function is necessary.  That is not the issue.
> >
> > What I do not understand is why that function must reside in a DLL and
> > not within the static WEL library.
> >
> > A DLL is essentially the same as a static library except that it is
> > identified, not linked, at the end of the compilation sequence.  A DLL
> > is typically chosen because it is needed by multiple clients and because
> > it is either more convenient or more space-efficient to distribute that
> > logic separately (rather than embedding it into every possibly client).
> > It is a question of form, not of function.
> >
> > As I see it, those advantages are no match for the serious disadvantage
> > of requiring that we distribute, install, locate and so forth an
> > additional file for our othewise ordinary Eiffel Vision apps.  It
> > effectively precludes offering a standalone application, and requires
> > some form of installation program.  That stinks.
> >
> > So, I will pose my question one more time.
> >
> > Why is is not possible to move the logic, currently in wel_hook.dll,
> > into the wel library?
> >
> >
> >      R
> >
> > ==================================================
> > Roger F. Osmond
> >
> >
> >  
> >> -------- Original Message --------
> >> Subject: Re: [eiffel_software] wel_hook.dll ?
> >> From: "Jocelyn Fiat [ES]" <[hidden email]>
> >> Date: Fri, September 25, 2009 9:51 am
> >> To: [hidden email]
> >> [hidden email] wrote:
> >>    
> >>> Hi Manu!
> >>>
> >>> More to the point, the dll must be in your path for it to be found.
> >>> If placed 'next to' your executable, it will work only if that place is
> >>> the working directory (it often is). The default working directory in
> >>> estudio workbench mode is the W_code directory, which is why placing it
> >>> there makes it work.
> >>>  
> >>>      
> >> Note that the default working directory when launched by EiffelStudio is
> >> the folder containing the .ecf file.
> >> This is not anymore the W_code since 6.3 (or 6.4)
> >> This change was made to help developer, then no need to copy test file,
> >> or pixmap, or dll in their W_code after each compilation (from scratch).
> >>    
> >>> Now, back to the gnarly part.
> >>> The reasons for having the function in wel_hook are clear thanks to you
> >>> earlier explanation, but my question about the reason for a DLL versus a
> >>> static library remain unanswered.  Why is that not an option?
> >>>  
> >>>      
> >> As Manu explained, we use the .dll in order to add a mouse (and
> >> keyboard) hook (system-wide hook).
> >> And this has to be done at the system level.
> >> Mainly because the application needs to be able to draw the P&D line
> >> (and also handle the Escape key) *when the mouse cursor is not over the
> >> Eiffel application.
> >> *This is how Windows works using dll.
> >> If ever you know another solution, then please let ISE know.
> >> hope this helps,
> >> Jocelyn
> >> PS: maybe the warning in the console might be annoying.
> >>    
> >>>      R
> >>>
> >>> ==================================================
> >>> Roger F. Osmond
> >>>
> >>>
> >>>  
> >>>      
> >>>> -------- Original Message --------
> >>>> Subject: RE: [eiffel_software] wel_hook.dll ?
> >>>> From: "Emmanuel Stapf [ES]" <[hidden email]>
> >>>> Date: Wed, September 23, 2009 12:29 pm
> >>>> To: <[hidden email]>
> >>>>    
> >>>>        
> >>>>> Manu, I think you must copy the dll to the w_code directory?  I know it
> >>>>> is not that much trouble but I seem to repeatedly delete the eifgen
> >>>>> directory (perhaps a bad habit pattern from earlier versions of
> >>>>> EiffelStudio no longer required).  But, is there a way to put the dll in
> >>>>> a more perminant directory and have systems pick up on it?
> >>>>>      
> >>>>>          
> >>>> Personally, I've created a directory `c:\bin' and added it to my PATH environment
> >>>> variable and this is where `wel_hook.dll' is. Of course this only works because it
> >>>> is my development machine. For deployment, you have to put `wel_hook.dll' next to
> >>>> your executable.
> >>>> Regards,
> >>>> Manu
> >>>>    
> >>>>        
> >>>
> >>> ------------------------------------
> >>>
> >>> Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>  
> >>>      
> >> --
> >> Jocelyn
> >> ------------------------------------------------------------------------  
> >> Eiffel Software
> >> 805-685-1006
> >> http://www.eiffel.com       
> >> Customer support: http://support.eiffel.com       
> >> User group: http://groups.eiffel.com/join       
> >> ------------------------------------------------------------------------
> >>    
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >  
> --
> Jocelyn
> ------------------------------------------------------------------------  
> Eiffel Software
> 805-685-1006
> http://www.eiffel.com       
> Customer support: http://support.eiffel.com       
> User group: http://groups.eiffel.com/join       
> ------------------------------------------------------------------------

[Jocelyn.Fiat.ES]

[hidden email] wrote:

> Hi Jocelyn!
>
> OK, I think I finally understand.  The wel_hook.dll is needed by other
> applications to see what the Eiffel application is doing, not by the
> Eiffel application itself.  That is why it must be a DLL.
>
> So the conclusion is that it still stinks, but it's not Eiffel's fault!
>
> It would seem that MS, with its legion of developers, would by now
> provide a capability-based registration mechanism rather the old
> name-based model that requires apps to provide their own DLLs.  It's
> soooo 1980s.
>  

Now, we might not be aware of recent advance of Windows on this part.
If ever there is a better solution, we'd love to hear it.

Unfortunately, I doubt there is any better solution for now (and which
works on all Windows platform since Windows 2000)
> Thanks for your help and you patience.
>  
You are welcome,
-- Jocelyn
>
>      R
>
> ==================================================
> Roger F. Osmond
>  

[Emmanuel Stapf]

> Now, we might not be aware of recent advance of Windows on this part.
> If ever there is a better solution, we'd love to hear it.

Actually there might be something better. The solution we had was the only solution available to us when we implemented it, because we needed to support Win9x and later. Now that we support from Win2k and higher, it changes things a bit. We are currently testing a new solution that does not require the DLL and so far so good. We cannot promise it will make it to 6.5 but we will do our best.

Thanks to Colin Le Mahieu for tipping us on this new API to use.

Regards,
Manu
 

[Peter Gummer-2]

Jocelyn Fiat [ES] wrote:

> Note that the default working directory when launched by  
> EiffelStudio is
> the folder containing the .ecf file.
> This is not anymore the W_code since 6.3 (or 6.4)
> This change was made to help developer, then no need to copy test  
> file,
> or pixmap, or dll in their W_code after each compilation (from  
> scratch).

That sounds useful.

I think that any application that is relying on the current working  
directory to find pixmaps, etc. has a pretty serious bug though. It's  
assuming that the current working directory is always going to be  
where the application was installed. This assumption falls over as  
soon as a user does this:

        $ cd ~
        $ path_where_my_app_is_installed/my_app

The current working directory is my home directory, but my application  
(and the files that it uses) are located elsewhere. And there are many  
other ways that the assumption might not hold.

So looking in the current working directory is the wrong way to do it.  
If these files are, in fact, installed in the same directory as the  
application executable, this is how we find them (with a friendly  
helping hand from Gobo):

        inherit
                KL_SHARED_FILE_SYSTEM
        ...
        application_startup_directory: STRING
                local
                        command: STRING
                        path: KI_PATHNAME
                once
                        command := (create {EXECUTION_ENVIRONMENT}).command_line.command_name
                        path := file_system.string_to_pathname  
(file_system.absolute_pathname (command))
                        path.set_canonical
                        Result := file_system.dirname (file_system.pathname_to_string (path))
                end

This isn't bullet-proof either, because this once function must be  
called before any change_dir calls are made. We avoid any trouble by  
making sure that we do call it during application start-up, when the  
current working directory is still the same as when the application  
was invoked by the user.

This doesn't address the issue that Jocelyn raised about launching the  
application within EiffelStudio. We solve this by an adjustment to the  
above code that treats the W/F_code directories as a special case.  
Again with Gobo's help, the once function's result goes three steps up  
the directory tree, so that the application is tricked into believing  
that it was launched from the .ecf file's folder. You can see the  
actual function here:

http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/specialisation/libraries/common_libs/src/utility/config_file/shared_resources.e

Works every time, on Windows, Mac  and Linux, regardless of how the  
user launches the application.

- Peter Gummer

[rfo]

Hi Peter (et al)

While it is clearly convenient to have your dlls in the same directory
as your core executable, it might be unacceptable in some circles
(though I personally rather like it).  On technical merit it's just
fine, but in some environments, the 'bin' directory doesn't have DLLs
(or .sos), as they are by convention kept in a 'lib' directory of some
sort.  Still, it's not unreasonable, and is certainly handy and more
predictable.

Having a "special case" (e.g. W/F_code) is always a concern of course,
but might not be such a big deal.  There is a potential risk, by
treating developement time differently than user time, that one might
run into mismatches when making the switch, but presumably the app is
tested in situ long before it sees a real user, so it seems pretty
reasonable over all.

By the way, the GOBO code in your example can be replaced (if anyone
wishes to do so for some reason) with a few more lines of inline code
(though I encourage any newbies out there to become familiar with GOBO),

----->
local
command: STRING
pos: INTEGER
once
command := (create {EXECUTION_ENVIRONMENT}).command_line.command_name
pos := command.last_index_of ((create
{OPERATING_ENVIRONMENT}).directory_separator, command.count)
if pos = 0 then
  Result := "."
else
  Result := command.substring (1, pos - 1)
end
end
<-----
If you wish to use the Amalasoft support library, then the same result
can be had with the following code.
----->
local
command: STRING
once
command := (create {EXECUTION_ENVIRONMENT}).command_line.command_name
Result := (create {AEL_SPRT_STRING_ROUTINES}).dirname (command)
end
<-----

The important message here is Peter's.  The CWD approach is handy, but
susceptible to errors during execution, and so the 'same place as
executable' approach is preferred.

While the 'same place as exececutable' approach has the benefit of
stability during process execution, it might ruffle a feather or two
culture-wise.

My message is:  I can hardly wait until we don't need a separate DLL for
fairly basic Eiffel Vision applications (thanks Manu!).

By the way, the 'where do I put this stuff' question is trickier for the
pixmaps.  Clearly they do not belong in a /bin.  Just as clearly, by
your DLL example, they do not belong in the current working directory
(though it works for estudio).
This problem bugs me so much that I have developed programmatically
generated pixmaps for all of the common toolbar icons.  That way, the
code is compiled-in and I don't have to worry about where those files
are, simply because there are no pixmap files.  The programmatic pixmaps
are available for free on the Amalasoft web site of course.

     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: Re: [eiffel_software] wel_hook.dll ?
> From: Peter Gummer <[hidden email]>
> Date: Fri, September 25, 2009 9:03 pm
> To: [hidden email]
> Jocelyn Fiat [ES] wrote:
> > Note that the default working directory when launched by  
> > EiffelStudio is
> > the folder containing the .ecf file.
> > This is not anymore the W_code since 6.3 (or 6.4)
> > This change was made to help developer, then no need to copy test  
> > file,
> > or pixmap, or dll in their W_code after each compilation (from  
> > scratch).
> That sounds useful.
> I think that any application that is relying on the current working  
> directory to find pixmaps, etc. has a pretty serious bug though. It's  
> assuming that the current working directory is always going to be  
> where the application was installed. This assumption falls over as  
> soon as a user does this:
> $ cd ~
> $ path_where_my_app_is_installed/my_app
> The current working directory is my home directory, but my application  
> (and the files that it uses) are located elsewhere. And there are many  
> other ways that the assumption might not hold.
> So looking in the current working directory is the wrong way to do it.  
> If these files are, in fact, installed in the same directory as the  
> application executable, this is how we find them (with a friendly  
> helping hand from Gobo):
> inherit
> KL_SHARED_FILE_SYSTEM
> ...
> application_startup_directory: STRING
> local
> command: STRING
> path: KI_PATHNAME
> once
> command := (create {EXECUTION_ENVIRONMENT}).command_line.command_name
> path := file_system.string_to_pathname  
> (file_system.absolute_pathname (command))
> path.set_canonical
> Result := file_system.dirname (file_system.pathname_to_string (path))
> end
> This isn't bullet-proof either, because this once function must be  
> called before any change_dir calls are made. We avoid any trouble by  
> making sure that we do call it during application start-up, when the  
> current working directory is still the same as when the application  
> was invoked by the user.
> This doesn't address the issue that Jocelyn raised about launching the  
> application within EiffelStudio. We solve this by an adjustment to the  
> above code that treats the W/F_code directories as a special case.  
> Again with Gobo's help, the once function's result goes three steps up  
> the directory tree, so that the application is tricked into believing  
> that it was launched from the .ecf file's folder. You can see the  
> actual function here:
> http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/specialisation/libraries/common_libs/src/utility/config_file/shared_resources.e
> Works every time, on Windows, Mac  and Linux, regardless of how the  
> user launches the application.
> - Peter Gummer