How to listen for microsoft os windows messages (WM_MESSAGE's)?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

How to listen for microsoft os windows messages (WM_MESSAGE's)?

lw1990
This post was updated on .
In the OS-Windows package, there exists the ability to use the windows api in Pharo.
This is very powerful, and I intend to add more of the windows api into it (it's only partially implemented).

This appears to all have been done with DllCalls (FFI calls) so far.

A big part of interacting with Microsoft Windows is listening to/intercepting and responding to Windows messages.
For example, every time a user presses a key on the keyboard, a windows message will happen in the background for that key. If Pharo was aware of these messages, then Pharo could do things in response to hotkeys pressed on Windows (outside of a pharo window).

It would also make reacting to events potentially nicer. Like making a windows-desktop-manager in Pharo that can tell when a new window is created by windows (maybe they opened notepad). It would certainly be better than an infinite loop or timer of 'get active window and compare to last active window and see if it changed'. Instead it would be 'when receive the WM_MESSAGE for new window created, notify Pharo so it can react'.

How can I set up a windows message hook in Pharo?
Please keep in mind I'm very new to programming, but I work from home and have lots of time to learn :-)
Reply | Threaded
Open this post in threaded view
|

Re: How to listen for windows messages?

Torsten Bergmann
Hi,

I guess what you want to achieve will not be an easy task for you if you are new to programming.
But it is always good to have a goal and if you have time to learn I'm pretty sure you will master
it.

Even when OS-Windows inspire you for automizing tasks in other Windows processes (like autoit) you
should not start with my OS-Windows project directly as contributing to it requires knowledge
on your side on Smalltalk as well as Win32 C programming.

First start with learning Smalltalk and Pharo
  - http://files.pharo.org/books/
  - http://pharo.pharocloud.com/pharobooks
  - http://stephane.ducasse.free.fr/FreeBooks.html

After having an idea about Smalltalk and Pharo you should try to learn UFFI which
is Pharos unified foreign function interface and ability to call C DLL's.

https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/

Sideways start learning about the Win32 API and C as this helps to better understand
how things are done on the Windows side. There are many, many tutorials out there.
Try to call or wrap some simple DLL functions on you own first.

There is a nice and tiny C compiler if you want to try out some C samples
http://www.pellesc.de/index.php?page=download&lang=en

With this initial knowledge you can try to understand why and how OS-Windows was done.
I wrote many tests - just add a breakpoint and run them to debug through the code to understand.
Google for the API descriptions of the Win32 functions that are called to get an understanding
how Pharo and C get connected.

Also check how you work with callbacks in UFFI (as this would be required for a hook).

If you are then still interested in interception windows messages you should start reading here
https://msdn.microsoft.com/en-us/library/windows/desktop/ms632589(v=vs.85).aspx
 
Primarily one has to wrap SetWindowsHookEx API function and friends and wrap a good API
for them in Pharo.

Hope that helps to get started.

Regards
Torsten

> Gesendet: Dienstag, 28. Februar 2017 um 06:04 Uhr
> Von: lw1990 <[hidden email]>
> An: [hidden email]
> Betreff: [Pharo-dev] How to listen for windows messages?
>
> In the OS-Windows package, there exists the ability to use the windows api in
> Pharo.
> This is very powerful, and I intend to add more of the windows api into it
> (it's only partially implemented).
>
> This appears to all have been done with DllCalls (FFI calls) so far.
>
> A big part of interacting with windows is listening to/intercepting and
> responding to windows messages.
> For example, every time a user presses a key on the keyboard, a windows
> message will happen in the background for that key. If Pharo was aware of
> these messages, then Pharo could do things in response to hotkeys pressed on
> Windows (outside of a pharo window).
>
> It would also make reacting to events potentially nicer. Like making a
> windows-desktop-manager in Pharo that can tell when a new window is created
> by windows (maybe they opened notepad). It would certainly be better than an
> infinite loop or timer of 'get active window and compare to last active
> window and see if it changed'. Instead it would be 'when receive the
> WM_MESSAGE for new window created, notify Pharo so it can react'.
>
> How can I set up a windows message hook in Pharo?
> Please keep in mind I'm very new to programming, but I work from home and
> have lots of time to learn :-)
>
>
>
> --
> View this message in context: http://forum.world.st/How-to-listen-for-windows-messages-tp4936285.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: How to listen for windows messages?

philippeback
Hi,

Pharo is itself a Windows application (under Windows of course).

So Window event loop is picking up the events and transforming them into Pharo events.

You can check this in https://github.com/pharo-project/pharo-vm

in opensmalltalk-vm\platforms\win32\vm\sqWin32Window.c

https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/platforms/win32/vm/sqWin32Window.c

Like L235...

LRESULT CALLBACK MainWndProcW(HWND hwnd,
UINT message,
WPARAM wParam,
LPARAM lParam)

You'll see that we stick a lot of stuff into evt->... in various ways.

There is a default fallback at the end.

default:
/* Unprocessed messages may be processed outside the current
module. If firstMessageHook is non-NULL and returns a non
zero value, the message has been successfully processed */
if(firstMessageHook)
if((*firstMessageHook)(hwnd, message, wParam, lParam))
return 1;
return DefWindowProcW(hwnd,message,wParam,lParam);


{


So, if firstMessageHook exists, one can do whatever.

Now, a Windows manager may need other stuff and so on.
What you are looking at is how to hook this VM side with more of the general Windows system.

These hooks are globals, so should be accessible.

/****************************************************************************/
/* Message Processing */
/****************************************************************************/
/* The last dispatched event. It is used for the event processing mechanism. */
MSG *lastMessage = NULL;
/* The entry to the message hooks called from the window procedure.
If another module requires to process messages by itself, it should
put its message procedure in this place. */
messageHook firstMessageHook = 0;
/* The entry to a pre-message hook. Can be used to intercept any messages
to the squeak main window. Useful for modules that wish to be notified
about certain messages before they are processed. */
messageHook preMessageHook = 0;

Never played with these but any Windows integration is of interest to me.

So, go ahead. Nothing would resist focused work.

Be aware that there is another VM underway with a cleanup of all of this but this is not released yet.

Keep us posted.
Phil



On Tue, Feb 28, 2017 at 9:33 AM, Torsten Bergmann <[hidden email]> wrote:

>
> Hi,
>
> I guess what you want to achieve will not be an easy task for you if you are new to programming.
> But it is always good to have a goal and if you have time to learn I'm pretty sure you will master
> it.
>
> Even when OS-Windows inspire you for automizing tasks in other Windows processes (like autoit) you
> should not start with my OS-Windows project directly as contributing to it requires knowledge
> on your side on Smalltalk as well as Win32 C programming.
>
> First start with learning Smalltalk and Pharo
>   - http://files.pharo.org/books/
>   - http://pharo.pharocloud.com/pharobooks
>   - http://stephane.ducasse.free.fr/FreeBooks.html
>
> After having an idea about Smalltalk and Pharo you should try to learn UFFI which
> is Pharos unified foreign function interface and ability to call C DLL's.
>
> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/
>
> Sideways start learning about the Win32 API and C as this helps to better understand
> how things are done on the Windows side. There are many, many tutorials out there.
> Try to call or wrap some simple DLL functions on you own first.
>
> There is a nice and tiny C compiler if you want to try out some C samples
> http://www.pellesc.de/index.php?page=download&lang=en
>
> With this initial knowledge you can try to understand why and how OS-Windows was done.
> I wrote many tests - just add a breakpoint and run them to debug through the code to understand.
> Google for the API descriptions of the Win32 functions that are called to get an understanding
> how Pharo and C get connected.
>
> Also check how you work with callbacks in UFFI (as this would be required for a hook).
>
> If you are then still interested in interception windows messages you should start reading here
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms632589(v=vs.85).aspx
>
> Primarily one has to wrap SetWindowsHookEx API function and friends and wrap a good API
> for them in Pharo.
>
> Hope that helps to get started.
>
> Regards
> Torsten
>
> > Gesendet: Dienstag, 28. Februar 2017 um 06:04 Uhr
> > Von: lw1990 <[hidden email]>
> > An: [hidden email]
> > Betreff: [Pharo-dev] How to listen for windows messages?
> >
> > In the OS-Windows package, there exists the ability to use the windows api in
> > Pharo.
> > This is very powerful, and I intend to add more of the windows api into it
> > (it's only partially implemented).
> >
> > This appears to all have been done with DllCalls (FFI calls) so far.
> >
> > A big part of interacting with windows is listening to/intercepting and
> > responding to windows messages.
> > For example, every time a user presses a key on the keyboard, a windows
> > message will happen in the background for that key. If Pharo was aware of
> > these messages, then Pharo could do things in response to hotkeys pressed on
> > Windows (outside of a pharo window).
> >
> > It would also make reacting to events potentially nicer. Like making a
> > windows-desktop-manager in Pharo that can tell when a new window is created
> > by windows (maybe they opened notepad). It would certainly be better than an
> > infinite loop or timer of 'get active window and compare to last active
> > window and see if it changed'. Instead it would be 'when receive the
> > WM_MESSAGE for new window created, notify Pharo so it can react'.
> >
> > How can I set up a windows message hook in Pharo?
> > Please keep in mind I'm very new to programming, but I work from home and
> > have lots of time to learn :-)
> >
> >
> >
> > --
> > View this message in context: http://forum.world.st/How-to-listen-for-windows-messages-tp4936285.html
> > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: How to listen for windows messages?

kilon.alios
In reply to this post by lw1990

How can I set up a windows message hook in Pharo?
Please keep in mind I'm very new to programming, but I work from home and
have lots of time to learn :-)

First of all Torsten gave you an excellent answer. If read it once, go reread it 10 times and bookmark it. Second of all I cannot answer precisely what code you will need because I have not done this before.

I did have a recent experience with UFFI. Apart from some of the basics of UFFI that you need to be aware of , everything else is pretty straightforward.
I did work with shared memory mapped files which is an extremely low level functionality of an OS, so low level that is included in the OS kernel and forms the basic of OS memory management. I expected to be insanely hard and I was suprised how simple it was. It started as a joke (how to make Pharo controll C++ applications) it turned out into a serious Pharo library (CPP).

The main reason for this is the fact that UFFI keeps the C syntax almost intact when it comes to function signatures. But the big catch here is that you need to be familiar with C and the libraries you are going to use. It will be super easy to use them from Pharo but the task itself may not. Pharo maybe be a higher level language but C is not. C is not low level but still you need to know how to do manual memory management and also OS APIs tend to be quite technical too.

The general idea is that Pharo will follow the C approach to the letter even when it comes to manual memory management. So if you do not know C , drop anything you do and go learn it NOW.

My advice is to NOT i repeat DO NOT do this in Pharo.

First do this in C.

Why ?

First of all you will find tons of example code online, so all you have to do is copy paste and modify accordingly.

So getting the code to work is suprisingly easy but understanding the code and why when you made changes started crashing for no apparent reason is a lot more difficult.

Second of all Pharo IDE may be awesome but is made to be used with Pharo not with C libraries. A C debugger and generally a C ide , in case of windows Visual Studio is free and very efficient will help you deal with bugs a lot easier.

When a bug happens in Pharo , the IDE practically takes you by the hand and helps you find it and correct it.

When a bug happens in C code , even C code run from inside Pharo via UFFI it will crash your C executable or Pharo itself and no error will be displayed apart from extremely limited information.

However this comparison is unfair because Pharo comes with an IDE , C usually does not.

But C with Visual Studio or other IDEs will help you get very close to Pharo experience. Obviously not the same , but quite close none the less.

Generally my approach was to start with prints , printing values and information to track exactly what went wrong with my C code . Then when prints became too many I used Visual Studio debugger breakpoints, that stop execution so you can examine what code is actually executed and fails and watchpoints which basically keep track of data inside variables so you can find bugs that are more tricky to find than executing the wrong code.

Also find a C forum and ask question. You wont get much help here because even though UFFI is very important the vast majority of Pharo coders prefer to stay away from C coding because C coding is not Pharo coding.

If you figure out how to do this in C it will take you literally minutes to port it to Pharo , its pretty much the exactly same process and exactly same code. Well almost. 

The process is the same for any C library and C code called from Pharo, the rest is just techncial documentation which you will find a ton online. Thats one of the advantages of using a popular language like C.

So go and do this in C and make sure it works in C then try to port it to Pharo. If Pharo gives you any problems you can always copy paste your code here, or preferably using an online code snippet service like pastebin or gist and we will guide you through how to fix your errors since the process is the same for all C code.
Reply | Threaded
Open this post in threaded view
|

Re: How to listen for microsoft os windows messages (WM_MESSAGE's)?

lw1990
This post was updated on .
In reply to this post by lw1990
Thank you all for the excellent replies
I will be rereading them, here are my thoughts/responses for now:

There exists a windows scripting language called autohotkey (autohotkey.com), similar to autoit, which does everything I want, I merely wanted to make similar functionality in Pharo so I could use Pharo - it will be better for large and ambitious windows projects.

So, most or all of the necessary C code is hopefully already available, I will just have to figure out how to put it into Pharo. It will not be as ambitious as Autohotkey itself because Pharo is its own superior programming language - all that is needed is the DllCall functionality from autohotkey for the Windows API to get/set values, hooks to be aware of Windows Messages, and perhaps one day an API to create native windows gui's using Pharo syntax. That is at least all of the main stuff I can think of that would be useful to most business people that want to automate their windows OS.

Side note: A native windows GUI API would not be needed if Pharo GUIs could be created flexibly - such as context menus, tooltips, etc. for third party native window controls. Autohotkey uses the native GUI functions, but Autohotkey can also use borderless browser windows and javascript/html/css components instead. I'm sure that the Pharo GUI packages are far superior to the native windows GUI components, just based on what I have seen in the Pharo programming environment. So that might save a lot of work too.

Pharo offers a very good IDE/debugger and programming environment, and natural language syntax which Autohotkey lacks. Autohotkey is the best there is right now for easy windows automation, but I believe Pharo could surpass it quickly once some of this functionality is implemented. The number one reason Autohotkey is easy to use is because the community is extremely responsive and helpful, and Pharo seems to be this way too :-)

The background information for why I am so interested in this:
I work with an industry software that is similar to AutoCAD but is enirely closed source with no API to speak of. Due to the immense complexity of this software and how specific it is, it is unlikely that in my lifetime I could create something better/faster than it for my workflow. What I am limited to doing to make my life immensely easier is creating macros for this software, even though it has no API, by using windows automation. The more information I can get about windows controls (buttons, edit boxes, treeviews, etc) and other native elements, the more I can create a pseudo API for this closed source software I am forced to use.

Using Autohotkey I'm already at least 30% faster at my workflow than I would be without it - and the potential is there for a lot of useful windows applications, autohotkey has variants of these but they get unruly fast and so they tend to not be maintained or elegant in the first place:
1) Automatic window manager (tile/arrange windows automatically, not just allow user to do it)
2) File manager (organize files automatically as new files are added, unzip files from archives as they are downloaded or copied from a USB, etc.)
3) Notification viewer/responder (combined email, social media, IRC/chat interface)
4) Program launcher/file finder/custom command browser (one text-field to rule them all interface, like an Omnibar for the desktop and browser and everything else - Pharo's Spotter comes close to this)

Ideally we would be using Linux or PharoOS or something but windows OS is probably going to dominate ordinary business people's lives for the immediate future, so might as well make life easier now.
Reply | Threaded
Open this post in threaded view
|

Re: How to listen for microsoft os windows messages (WM_MESSAGE's)?

kilon.alios
The first thing is to be very precise in what you want.

I thought you wanted a window manager now you mention a full blow GUI API.

Frankly if you want to ovehaul Pharo GUI API , personally I think hands down a Pharo QT project will be far more valuable.

Windows may have an overwhelming market of 90% of OS users but the same is not true for developers. Developers are far more attracted to other platforms like MacOS and Linux. MacOS especially has a very loyal and quite large developer crowd. So a WIN API solution will not be as attractive as cross platform QT.

QT not only work on Win, Mac and Linux , it also work inside Web pages , iOS and Android.  If we take into account that mobile is the most rapidly growing market you can imagine why QT is so much loved by devs.

I also recommend to get your hands dirty and learn C. Yes there are easier solutions out there, much easier, but knowing C does not open a door it opens a multiverse of possibilities. Its a huge bonus to have in your coding arsenal. C and C++ may not be as loved as Pharo but its a necessary evil none the less.

There is also the .NET options which provided the native gui on widnows and recently it open sourced and gained support from Microsoft for other platforms. Basically M$ bought Xamarin , the company responsible for MONO , a .NET that can run on pretty much any platform with support for C#, Python, Delphi, J#, F# and many other langauges.

But personally I do not trust Microsoft.

In any case using an existing GUI API will make your life eaiser. Both QT and Winforms (.NET GUI API) are very well designed but Win API (especially MFC) are a monstrosity.

Another solution is to get your hands dirty and help with Bloc, the new replacement for Morphic which is the standard Pharo GUI API. I am sure Bloc devs would love your assistance and Bloc already works well so it will be eaiser for you too. You can instead focus on features you care the most and bring those features inside Bloc or as a separate Pharo library depending on Bloc. 

This will be extremely valuable for your Pharo user because we will be moving to Bloc slowly next year and thus they wont have to learn a new GUI API.
Hence why I said that you need to define a precise strategy. Pitch your ideas , discuss them here, see if there devs already working on similar features.

You will be surprised how much "buried" Pharo code there is out there. People make it for personal use and never both to advertise it or even mention it.

Coders are generally terrible at 3 things

1) GUIs
2) Code design
3) Promotion

On Tue, Feb 28, 2017 at 3:17 PM lw1990 <[hidden email]> wrote:
Thank you all for the excellent replies
I will be rereading them, here are my thoughts/responses for now:

There exists a windows scripting language called autohotkey
(autohotkey.com), similar to autoit, which does everything I want, I merely
wanted to make similar functionality in Pharo so I could use Pharo - it will
be better for large and ambitious windows projects.

AutoHotkey is open source and the source of the language is in C.

So, most or all of the necessary C code is hopefully already available, I
will just have to figure out how to put it into Pharo. It will not be as
ambitious as Autohotkey itself because Pharo has most of the functionality
required by default - all that is needed is DllCall's for the Windows API to
get/set values, hooks to be aware of Windows Messages, and perhaps one day
an API to create native windows gui's using Pharo syntax. That is at least
all of the main stuff I can think of that would be useful to most business
people that want to automate their windows OS.

Pharo offers a very good IDE/debugger and programming environment, and
natural language syntax which Autohotkey lacks. Autohotkey is the best there
is right now, but I believe Pharo could surpass it quickly once some of this
functionality is implemented. The number one reason Autohotkey is easy to
use is because the community is extremely responsive and helpful, and Pharo
seems to be this way too :-)



--
View this message in context: http://forum.world.st/How-to-listen-for-microsoft-os-windows-messages-WM-MESSAGE-s-tp4936285p4936388.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: How to listen for microsoft os windows messages (WM_MESSAGE's)?

bestlem
On 28/02/2017 14:05, Dimitris Chloupis wrote:
> The first thing is to be very precise in what you want.
>
I think this is the most important thing to do first.

> I thought you wanted a window manager now you mention a full blow GUI API.
>

You could also look at Dolphin Smalltalk http://object-arts.com/ which
is integrated with Windows GUI - albeit 32 bit only

> Frankly if you want to ovehaul Pharo GUI API , personally I think hands
> down a Pharo QT project will be far more valuable.
>
> Windows may have an overwhelming market of 90% of OS users but the same
> is not true for developers. Developers are far more attracted to other
> platforms like MacOS and Linux. MacOS especially has a very loyal and
> quite large developer crowd. So a WIN API solution will not be as
> attractive as cross platform QT.
>
> QT not only work on Win, Mac and Linux , it also work inside Web pages ,
> iOS and Android.  If we take into account that mobile is the most
> rapidly growing market you can imagine why QT is so much loved by devs.
>

There are other cross platform APIs e.g. wxWidgets and Gtk

There used to be a version of squeak with wx bindings wxSqueak but the
code seems not to be on line now.


  Pharo had some GTK bindings in Mars https://marsonpharo.wordpress.com/

The last two don't work at all now but might help you by giving ideas.








Reply | Threaded
Open this post in threaded view
|

Re: How to listen for microsoft os windows messages (WM_MESSAGE's)?

Eliot Miranda-2
In reply to this post by lw1990
Hi Luke,

On Tue, Feb 28, 2017 at 5:11 AM, lw1990 <[hidden email]> wrote:
Thank you all for the excellent replies
I will be rereading them, here are my thoughts/responses for now:

There exists a windows scripting language called autohotkey
(autohotkey.com), similar to autoit, which does everything I want, I merely
wanted to make similar functionality in Pharo so I could use Pharo - it will
be better for large and ambitious windows projects.

AutoHotkey is open source and the source of the language is in C.

So, most or all of the necessary C code is hopefully already available, I
will just have to figure out how to put it into Pharo. It will not be as
ambitious as Autohotkey itself because Pharo has most of the functionality
required by default - all that is needed is DllCall's for the Windows API to
get/set values, hooks to be aware of Windows Messages, and perhaps one day
an API to create native windows gui's using Pharo syntax. That is at least
all of the main stuff I can think of that would be useful to most business
people that want to automate their windows OS.

Pharo offers a very good IDE/debugger and programming environment, and
natural language syntax which Autohotkey lacks. Autohotkey is the best there
is right now, but I believe Pharo could surpass it quickly once some of this
functionality is implemented. The number one reason Autohotkey is easy to
use is because the community is extremely responsive and helpful, and Pharo
seems to be this way too :-)

There is a complete integration of the Windows event loop in Newspeak, written by Vassili Bykov.  It is implemented above the same Alien callbacks we have in Pharo and Squeak, which use slightly different, but mostly common versions of the same VM.  If you're looking to integrate with Windows events I suggest contacting the newspeaklanguage group and asking there for assistance in porting the code to Pharo.

--
View this message in context: http://forum.world.st/How-to-listen-for-microsoft-os-windows-messages-WM-MESSAGE-s-tp4936285p4936388.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: How to listen for microsoft os windows messages (WM_MESSAGE's)?

kilon.alios
In reply to this post by bestlem


There are other cross platform APIs e.g. wxWidgets and Gtk

There used to be a version of squeak with wx bindings wxSqueak but the
code seems not to be on line now.


GTK is not a very good choice, it works well on Linux but on MacOS and Windows has many issues and a lot less developers bug fixing.

wxWidgets is a nice GUI API but again it does not come remotely close to the feature set and stability of QT. Some of its areas also are abandoned or very much lagging behind. In my case a big turn off was the outdated python wrappers which sent me directly back to QT.

When it comes to guis No1 is Native GUIs , No2 is QT.

But QT needs a commercial license for developing pro applications. Its free license is GLP which limits the usage on commercial projects.

It does however offer a free LGPL version with more limited features. LGPL allows to close code as long as the code is distributed via dynamically linked libraries.

Still it may be tricky to balance on the LGPL without falling down. Which is why many like us prefer MIT over LGPL.

There are a ton of open source GUI APIs out there, but most of them are immature, limited or plain abandoned. So you have plenty of choice, but I think you will have little reason to prefer something that is not QT, especially if we are talking about commercial projects that need to run on many platforms.  
Reply | Threaded
Open this post in threaded view
|

Re: How to listen for microsoft os windows messages (WM_MESSAGE's)?

EstebanLM
you cannot use QT out of the box because is C++

I have some experiments with GTK3 that were working but event loop was kinda failing (no time to go back to it soon). 
It would be very interesting to have native windows support, I may take a look eventually :)

Esteban

On 14 Mar 2017, at 13:37, Dimitris Chloupis <[hidden email]> wrote:



There are other cross platform APIs e.g. wxWidgets and Gtk

There used to be a version of squeak with wx bindings wxSqueak but the
code seems not to be on line now.


GTK is not a very good choice, it works well on Linux but on MacOS and Windows has many issues and a lot less developers bug fixing.

wxWidgets is a nice GUI API but again it does not come remotely close to the feature set and stability of QT. Some of its areas also are abandoned or very much lagging behind. In my case a big turn off was the outdated python wrappers which sent me directly back to QT.

When it comes to guis No1 is Native GUIs , No2 is QT.

But QT needs a commercial license for developing pro applications. Its free license is GLP which limits the usage on commercial projects.

It does however offer a free LGPL version with more limited features. LGPL allows to close code as long as the code is distributed via dynamically linked libraries.

Still it may be tricky to balance on the LGPL without falling down. Which is why many like us prefer MIT over LGPL.

There are a ton of open source GUI APIs out there, but most of them are immature, limited or plain abandoned. So you have plenty of choice, but I think you will have little reason to prefer something that is not QT, especially if we are talking about commercial projects that need to run on many platforms.  

Reply | Threaded
Open this post in threaded view
|

Re: How to listen for windows messages?

Eliot Miranda-2
In reply to this post by philippeback
Hi Phil, Hi All,

On Tue, Feb 28, 2017 at 4:29 AM, [hidden email] <[hidden email]> wrote:
Hi,

Pharo is itself a Windows application (under Windows of course).

So Window event loop is picking up the events and transforming them into Pharo events.

Right, but this is *not good enough* :-)  It is a fundamentally different architecture.  The processing of Windows events in the Windows VM transforms *event callbacks* into   an *event queue*.  This is fine for events such as mouse clicks, keyboard presses, etc.  But it is fundamentally broken for events such as those that ask an application to quit because the OS is about to exit, or events that try to obtain mouse feedback while moving a native window, etc, etc.

So one either needs to extend the VM event queue so that one can install callbacks for certain kinds of events still providing a cross-platform interface), or, as Vassili did for Newspeak native windows (which was fully working in 2008, with the ability to switch a window between emulated (Morphic) and native at will or on image startup), interface to the native Windows event pump via callbacks.



You can check this in https://github.com/pharo-project/pharo-vm

in opensmalltalk-vm\platforms\win32\vm\sqWin32Window.c

https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/platforms/win32/vm/sqWin32Window.c

Like L235...

LRESULT CALLBACK MainWndProcW(HWND hwnd,
UINT message,
WPARAM wParam,
LPARAM lParam)

You'll see that we stick a lot of stuff into evt->... in various ways.

There is a default fallback at the end.

default:
/* Unprocessed messages may be processed outside the current
module. If firstMessageHook is non-NULL and returns a non
zero value, the message has been successfully processed */
if(firstMessageHook)
if((*firstMessageHook)(hwnd, message, wParam, lParam))
return 1;
return DefWindowProcW(hwnd,message,wParam,lParam);


{


So, if firstMessageHook exists, one can do whatever.

Now, a Windows manager may need other stuff and so on.
What you are looking at is how to hook this VM side with more of the general Windows system.

These hooks are globals, so should be accessible.

/****************************************************************************/
/* Message Processing */
/****************************************************************************/
/* The last dispatched event. It is used for the event processing mechanism. */
MSG *lastMessage = NULL;
/* The entry to the message hooks called from the window procedure.
If another module requires to process messages by itself, it should
put its message procedure in this place. */
messageHook firstMessageHook = 0;
/* The entry to a pre-message hook. Can be used to intercept any messages
to the squeak main window. Useful for modules that wish to be notified
about certain messages before they are processed. */
messageHook preMessageHook = 0;

Never played with these but any Windows integration is of interest to me.

So, go ahead. Nothing would resist focused work.

Be aware that there is another VM underway with a cleanup of all of this but this is not released yet.

Keep us posted.
Phil




On Tue, Feb 28, 2017 at 9:33 AM, Torsten Bergmann <[hidden email]> wrote:

>
> Hi,
>
> I guess what you want to achieve will not be an easy task for you if you are new to programming.
> But it is always good to have a goal and if you have time to learn I'm pretty sure you will master
> it.
>
> Even when OS-Windows inspire you for automizing tasks in other Windows processes (like autoit) you
> should not start with my OS-Windows project directly as contributing to it requires knowledge
> on your side on Smalltalk as well as Win32 C programming.
>
> First start with learning Smalltalk and Pharo
>   - http://files.pharo.org/books/
>   - http://pharo.pharocloud.com/pharobooks
>   - http://stephane.ducasse.free.fr/FreeBooks.html
>
> After having an idea about Smalltalk and Pharo you should try to learn UFFI which
> is Pharos unified foreign function interface and ability to call C DLL's.
>
> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/
>
> Sideways start learning about the Win32 API and C as this helps to better understand
> how things are done on the Windows side. There are many, many tutorials out there.
> Try to call or wrap some simple DLL functions on you own first.
>
> There is a nice and tiny C compiler if you want to try out some C samples
> http://www.pellesc.de/index.php?page=download&lang=en
>
> With this initial knowledge you can try to understand why and how OS-Windows was done.
> I wrote many tests - just add a breakpoint and run them to debug through the code to understand.
> Google for the API descriptions of the Win32 functions that are called to get an understanding
> how Pharo and C get connected.
>
> Also check how you work with callbacks in UFFI (as this would be required for a hook).
>
> If you are then still interested in interception windows messages you should start reading here
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms632589(v=vs.85).aspx
>
> Primarily one has to wrap SetWindowsHookEx API function and friends and wrap a good API
> for them in Pharo.
>
> Hope that helps to get started.
>
> Regards
> Torsten
>
> > Gesendet: Dienstag, 28. Februar 2017 um 06:04 Uhr
> > Von: lw1990 <[hidden email]>
> > An: [hidden email]
> > Betreff: [Pharo-dev] How to listen for windows messages?
> >
> > In the OS-Windows package, there exists the ability to use the windows api in
> > Pharo.
> > This is very powerful, and I intend to add more of the windows api into it
> > (it's only partially implemented).
> >
> > This appears to all have been done with DllCalls (FFI calls) so far.
> >
> > A big part of interacting with windows is listening to/intercepting and
> > responding to windows messages.
> > For example, every time a user presses a key on the keyboard, a windows
> > message will happen in the background for that key. If Pharo was aware of
> > these messages, then Pharo could do things in response to hotkeys pressed on
> > Windows (outside of a pharo window).
> >
> > It would also make reacting to events potentially nicer. Like making a
> > windows-desktop-manager in Pharo that can tell when a new window is created
> > by windows (maybe they opened notepad). It would certainly be better than an
> > infinite loop or timer of 'get active window and compare to last active
> > window and see if it changed'. Instead it would be 'when receive the
> > WM_MESSAGE for new window created, notify Pharo so it can react'.
> >
> > How can I set up a windows message hook in Pharo?
> > Please keep in mind I'm very new to programming, but I work from home and
> > have lots of time to learn :-)
> >
> >
> >
> > --
> > View this message in context: http://forum.world.st/How-to-listen-for-windows-messages-tp4936285.html
> > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> >
> >
>



--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: How to listen for windows messages?

philippeback


On Tue, Mar 14, 2017 at 4:27 PM, Eliot Miranda <[hidden email]> wrote:
Hi Phil, Hi All,

On Tue, Feb 28, 2017 at 4:29 AM, [hidden email] <[hidden email]> wrote:
Hi,

Pharo is itself a Windows application (under Windows of course).

So Window event loop is picking up the events and transforming them into Pharo events.

Right, but this is *not good enough* :-)  It is a fundamentally different architecture.  The processing of Windows events in the Windows VM transforms *event callbacks* into   an *event queue*.  This is fine for events such as mouse clicks, keyboard presses, etc.  But it is fundamentally broken for events such as those that ask an application to quit because the OS is about to exit, or events that try to obtain mouse feedback while moving a native window, etc, etc.

So one either needs to extend the VM event queue so that one can install callbacks for certain kinds of events still providing a cross-platform interface), or, as Vassili did for Newspeak native windows (which was fully working in 2008, with the ability to switch a window between emulated (Morphic) and native at will or on image startup), interface to the native Windows event pump via callbacks.

Yes, I understand that. But there is some bit rot in the basics already, so, first things first.  And Pharo lowcode VM is also replacing a lot of this with other ways (which kind of bury the Windows thing even deeper in way I guess).

Would the VM core be a libray, we could have more options. Look at V8 ending up in Chrome, NodeJS and Electron.
Or Lua getting all over the place. Tcl also is pretty cool on that front.

Phil



You can check this in https://github.com/pharo-project/pharo-vm

in opensmalltalk-vm\platforms\win32\vm\sqWin32Window.c

https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/platforms/win32/vm/sqWin32Window.c

Like L235...

LRESULT CALLBACK MainWndProcW(HWND hwnd,
UINT message,
WPARAM wParam,
LPARAM lParam)

You'll see that we stick a lot of stuff into evt->... in various ways.

There is a default fallback at the end.

default:
/* Unprocessed messages may be processed outside the current
module. If firstMessageHook is non-NULL and returns a non
zero value, the message has been successfully processed */
if(firstMessageHook)
if((*firstMessageHook)(hwnd, message, wParam, lParam))
return 1;
return DefWindowProcW(hwnd,message,wParam,lParam);


{


So, if firstMessageHook exists, one can do whatever.

Now, a Windows manager may need other stuff and so on.
What you are looking at is how to hook this VM side with more of the general Windows system.

These hooks are globals, so should be accessible.

/****************************************************************************/
/* Message Processing */
/****************************************************************************/
/* The last dispatched event. It is used for the event processing mechanism. */
MSG *lastMessage = NULL;
/* The entry to the message hooks called from the window procedure.
If another module requires to process messages by itself, it should
put its message procedure in this place. */
messageHook firstMessageHook = 0;
/* The entry to a pre-message hook. Can be used to intercept any messages
to the squeak main window. Useful for modules that wish to be notified
about certain messages before they are processed. */
messageHook preMessageHook = 0;

Never played with these but any Windows integration is of interest to me.

So, go ahead. Nothing would resist focused work.

Be aware that there is another VM underway with a cleanup of all of this but this is not released yet.

Keep us posted.
Phil




On Tue, Feb 28, 2017 at 9:33 AM, Torsten Bergmann <[hidden email]> wrote:

>
> Hi,
>
> I guess what you want to achieve will not be an easy task for you if you are new to programming.
> But it is always good to have a goal and if you have time to learn I'm pretty sure you will master
> it.
>
> Even when OS-Windows inspire you for automizing tasks in other Windows processes (like autoit) you
> should not start with my OS-Windows project directly as contributing to it requires knowledge
> on your side on Smalltalk as well as Win32 C programming.
>
> First start with learning Smalltalk and Pharo
>   - http://files.pharo.org/books/
>   - http://pharo.pharocloud.com/pharobooks
>   - http://stephane.ducasse.free.fr/FreeBooks.html
>
> After having an idea about Smalltalk and Pharo you should try to learn UFFI which
> is Pharos unified foreign function interface and ability to call C DLL's.
>
> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/
>
> Sideways start learning about the Win32 API and C as this helps to better understand
> how things are done on the Windows side. There are many, many tutorials out there.
> Try to call or wrap some simple DLL functions on you own first.
>
> There is a nice and tiny C compiler if you want to try out some C samples
> http://www.pellesc.de/index.php?page=download&lang=en
>
> With this initial knowledge you can try to understand why and how OS-Windows was done.
> I wrote many tests - just add a breakpoint and run them to debug through the code to understand.
> Google for the API descriptions of the Win32 functions that are called to get an understanding
> how Pharo and C get connected.
>
> Also check how you work with callbacks in UFFI (as this would be required for a hook).
>
> If you are then still interested in interception windows messages you should start reading here
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms632589(v=vs.85).aspx
>
> Primarily one has to wrap SetWindowsHookEx API function and friends and wrap a good API
> for them in Pharo.
>
> Hope that helps to get started.
>
> Regards
> Torsten
>
> > Gesendet: Dienstag, 28. Februar 2017 um 06:04 Uhr
> > Von: lw1990 <[hidden email]>
> > An: [hidden email]
> > Betreff: [Pharo-dev] How to listen for windows messages?
> >
> > In the OS-Windows package, there exists the ability to use the windows api in
> > Pharo.
> > This is very powerful, and I intend to add more of the windows api into it
> > (it's only partially implemented).
> >
> > This appears to all have been done with DllCalls (FFI calls) so far.
> >
> > A big part of interacting with windows is listening to/intercepting and
> > responding to windows messages.
> > For example, every time a user presses a key on the keyboard, a windows
> > message will happen in the background for that key. If Pharo was aware of
> > these messages, then Pharo could do things in response to hotkeys pressed on
> > Windows (outside of a pharo window).
> >
> > It would also make reacting to events potentially nicer. Like making a
> > windows-desktop-manager in Pharo that can tell when a new window is created
> > by windows (maybe they opened notepad). It would certainly be better than an
> > infinite loop or timer of 'get active window and compare to last active
> > window and see if it changed'. Instead it would be 'when receive the
> > WM_MESSAGE for new window created, notify Pharo so it can react'.
> >
> > How can I set up a windows message hook in Pharo?
> > Please keep in mind I'm very new to programming, but I work from home and
> > have lots of time to learn :-)
> >
> >
> >
> > --
> > View this message in context: http://forum.world.st/How-to-listen-for-windows-messages-tp4936285.html
> > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> >
> >
>



--
_,,,^..^,,,_
best, Eliot

Reply | Threaded
Open this post in threaded view
|

Re: How to listen for microsoft os windows messages (WM_MESSAGE's)?

kilon.alios
In reply to this post by EstebanLM
True but if you want to work with GUI and Graphics APIs its C++ all the way. Mainly because Graphics are extremely complex data that benefits from the workflow of OOP and the performance of C. Combine the two and you have C++. The language we all love to hate.

I have not tried myself , but I think C++ compilers have an option for disabling name mangling that is the reasons UFFI cannot use C++ libraries. But there is of course always the option of making a wrapper DLL in C++ that has no name mangling with EXTERN C keyword.


On Tue, Mar 14, 2017 at 4:23 PM Esteban Lorenzano <[hidden email]> wrote:
you cannot use QT out of the box because is C++

I have some experiments with GTK3 that were working but event loop was kinda failing (no time to go back to it soon). 
It would be very interesting to have native windows support, I may take a look eventually :)

Esteban

On 14 Mar 2017, at 13:37, Dimitris Chloupis <[hidden email]> wrote:



There are other cross platform APIs e.g. wxWidgets and Gtk

There used to be a version of squeak with wx bindings wxSqueak but the
code seems not to be on line now.


GTK is not a very good choice, it works well on Linux but on MacOS and Windows has many issues and a lot less developers bug fixing.

wxWidgets is a nice GUI API but again it does not come remotely close to the feature set and stability of QT. Some of its areas also are abandoned or very much lagging behind. In my case a big turn off was the outdated python wrappers which sent me directly back to QT.

When it comes to guis No1 is Native GUIs , No2 is QT.

But QT needs a commercial license for developing pro applications. Its free license is GLP which limits the usage on commercial projects.

It does however offer a free LGPL version with more limited features. LGPL allows to close code as long as the code is distributed via dynamically linked libraries.

Still it may be tricky to balance on the LGPL without falling down. Which is why many like us prefer MIT over LGPL.

There are a ton of open source GUI APIs out there, but most of them are immature, limited or plain abandoned. So you have plenty of choice, but I think you will have little reason to prefer something that is not QT, especially if we are talking about commercial projects that need to run on many platforms.