C++ SendMessage
-
I need to send a WM message to a thread. Is there a substitute for SendMessage? And, incidentally, is there a PostMessage equivalent? Thanks, -Keivn
if you want to send a message in c#, here is the way to declare ... [DllImport("user32.dll",EntryPoint="SendMessage",ExactSpelling=false,SetLastError=true)] private static extern int SendMessage(int hwnd,int wMsg,int wParam,int lParam); [DllImport("user32.dll",,EntryPoint="PostMessage",ExactSpelling=false,SetLastError=true)] private static extern int PostMessage(int hwnd,int wMsg,int wParam,int lParam); Hope this helps.. Thanks
-
if you want to send a message in c#, here is the way to declare ... [DllImport("user32.dll",EntryPoint="SendMessage",ExactSpelling=false,SetLastError=true)] private static extern int SendMessage(int hwnd,int wMsg,int wParam,int lParam); [DllImport("user32.dll",,EntryPoint="PostMessage",ExactSpelling=false,SetLastError=true)] private static extern int PostMessage(int hwnd,int wMsg,int wParam,int lParam); Hope this helps.. Thanks
-
Cool, thanks. I was just wondering if there was some C# or .NET way of doing this. They seem to abstract nearly everything else but I guess abstracting this would be getting too far away from an OS/hardware neutral language. Thanks for the info, -Kevin
Agreed. ;) That's the big trick (or lie, depending on the irony level) behind the DotNet framework. It is supposed to be interoperable, or even cross-platform and what people do is SendMessage or other things. In articles such like these, the author uses a utility wrapper for a significant portion of the win32 API. It looks like when you have to go through lower-level code, the uses of messages, notifications and so on is inevitable. IMHO, MS is not to blame for disabling it entirely in C# (this is btw is almost impossible as the whole operating system is based on windows messaging). MS is to blame for providing an overridable WndProc(message) method for most C# UI controls, which indeed tends to make us keep the former approach. What I would expect for DotNet 2.0 later in 2003 is a finished product, with a rich eventsubscriber-based mechanism that, especially when run on Windows, is exactly translated in lower layers as known windows messages and notifications. Or else provide richer API for most C# UI controls so that when we need to use owner drawing, we don't need to rely on WM_ stuff.
-
Agreed. ;) That's the big trick (or lie, depending on the irony level) behind the DotNet framework. It is supposed to be interoperable, or even cross-platform and what people do is SendMessage or other things. In articles such like these, the author uses a utility wrapper for a significant portion of the win32 API. It looks like when you have to go through lower-level code, the uses of messages, notifications and so on is inevitable. IMHO, MS is not to blame for disabling it entirely in C# (this is btw is almost impossible as the whole operating system is based on windows messaging). MS is to blame for providing an overridable WndProc(message) method for most C# UI controls, which indeed tends to make us keep the former approach. What I would expect for DotNet 2.0 later in 2003 is a finished product, with a rich eventsubscriber-based mechanism that, especially when run on Windows, is exactly translated in lower layers as known windows messages and notifications. Or else provide richer API for most C# UI controls so that when we need to use owner drawing, we don't need to rely on WM_ stuff.
I'd agree with that prediction. MS already bit the bullet and included the Microsoft.Win32 namespace but all they included of any use is Registry handling (although that is such a nightmare when using the API in VB, having to fill out the strings for accepting the values, it's no surprise that it was a priority here). I'm sure Windows Messaging will be the next thing they have to give in on, it's too fundamental, even if it is easy enough to import. On the whole, I don't think people will see it as a break-down in the "multi-platform" thinking. If you want to write a multi-platform program for the mythical "other" platforms that will support a DotNet Framework, you stay away from the Microsoft Namespace; you're probably not going to want to access the registry or send any windows messages anyway. But you've still got to be able to use the full Windows API readily if you feel the need and don't give a damn about other platforms. I'm sure the DotNet team will see this... eventually. :rolleyes:
-
Agreed. ;) That's the big trick (or lie, depending on the irony level) behind the DotNet framework. It is supposed to be interoperable, or even cross-platform and what people do is SendMessage or other things. In articles such like these, the author uses a utility wrapper for a significant portion of the win32 API. It looks like when you have to go through lower-level code, the uses of messages, notifications and so on is inevitable. IMHO, MS is not to blame for disabling it entirely in C# (this is btw is almost impossible as the whole operating system is based on windows messaging). MS is to blame for providing an overridable WndProc(message) method for most C# UI controls, which indeed tends to make us keep the former approach. What I would expect for DotNet 2.0 later in 2003 is a finished product, with a rich eventsubscriber-based mechanism that, especially when run on Windows, is exactly translated in lower layers as known windows messages and notifications. Or else provide richer API for most C# UI controls so that when we need to use owner drawing, we don't need to rely on WM_ stuff.
In a way, it could just be an extension of delegates, couldn't it? Currently delegates just become function calls, but you could, I guess, have different delegate classes with different implementations, sending windows messages instead? It's all just implementation detail... Stuart Dootson 'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
-
Agreed. ;) That's the big trick (or lie, depending on the irony level) behind the DotNet framework. It is supposed to be interoperable, or even cross-platform and what people do is SendMessage or other things. In articles such like these, the author uses a utility wrapper for a significant portion of the win32 API. It looks like when you have to go through lower-level code, the uses of messages, notifications and so on is inevitable. IMHO, MS is not to blame for disabling it entirely in C# (this is btw is almost impossible as the whole operating system is based on windows messaging). MS is to blame for providing an overridable WndProc(message) method for most C# UI controls, which indeed tends to make us keep the former approach. What I would expect for DotNet 2.0 later in 2003 is a finished product, with a rich eventsubscriber-based mechanism that, especially when run on Windows, is exactly translated in lower layers as known windows messages and notifications. Or else provide richer API for most C# UI controls so that when we need to use owner drawing, we don't need to rely on WM_ stuff.
StephaneRodriguez wrote: It is supposed to be interoperable, or even cross-platform It *is* interoperable and cross-platform when you focus on the parts of the framework that hold that promise. Windows Forms, ADO.NET, ASP.NET among other technologies are not part of the CLI which is portion of the framework carrying that promise. Other projects such as Mono are working on bringing over the non-CLI parts. James "And we are all men; apart from the females." - Colin Davies
-
StephaneRodriguez wrote: It is supposed to be interoperable, or even cross-platform It *is* interoperable and cross-platform when you focus on the parts of the framework that hold that promise. Windows Forms, ADO.NET, ASP.NET among other technologies are not part of the CLI which is portion of the framework carrying that promise. Other projects such as Mono are working on bringing over the non-CLI parts. James "And we are all men; apart from the females." - Colin Davies
Interoperable ? Not sure. If we forget UI or other application layers, and go down to the simplest types such like "int" and "char", then if we refer to the MSDN documentation is is clearly said that : - "int" is 32 bits : how does it cope with 64-bit oses ready this year? - "char" is 16bits : how does it cope with the latest Unicode additions (I have read somewhere that 30 000 symbols have been added lately) ? I don't know if the documentation showed this mapping just to give a snapshot reference while remaining essentially dynamical, or if it is hardcoded once for all. In the second case, C# is just C without pointers. There is no more interoperability in it. To add to the irony, I have to argue that WindowsCE is with the .Net framework not even part of their strategy, as (as for what I have seen so far) no method implementation targets this platform. In fact, what MS calls interoperable is on the one hand interoperable across their own Windows platforms (not between Sun,HP,S/390,...). On the other hand, they actually cannot stand this either : VisualStudio.Net does not target PDAs or other devices. The Mobile internet toolkit looks like an application layer, not a framework layer. AFAIK, I want MS to be able to ensure developers that at least a program developed targeting for instance WIN2000 can actually be run on any WIN2000 consumer machine. This sounds stupid, but why should I spend time developing software that someone else will not be able to run ? This happen to have been a failure for many of MS APIs, including DirectX. Regards:-D
-
Interoperable ? Not sure. If we forget UI or other application layers, and go down to the simplest types such like "int" and "char", then if we refer to the MSDN documentation is is clearly said that : - "int" is 32 bits : how does it cope with 64-bit oses ready this year? - "char" is 16bits : how does it cope with the latest Unicode additions (I have read somewhere that 30 000 symbols have been added lately) ? I don't know if the documentation showed this mapping just to give a snapshot reference while remaining essentially dynamical, or if it is hardcoded once for all. In the second case, C# is just C without pointers. There is no more interoperability in it. To add to the irony, I have to argue that WindowsCE is with the .Net framework not even part of their strategy, as (as for what I have seen so far) no method implementation targets this platform. In fact, what MS calls interoperable is on the one hand interoperable across their own Windows platforms (not between Sun,HP,S/390,...). On the other hand, they actually cannot stand this either : VisualStudio.Net does not target PDAs or other devices. The Mobile internet toolkit looks like an application layer, not a framework layer. AFAIK, I want MS to be able to ensure developers that at least a program developed targeting for instance WIN2000 can actually be run on any WIN2000 consumer machine. This sounds stupid, but why should I spend time developing software that someone else will not be able to run ? This happen to have been a failure for many of MS APIs, including DirectX. Regards:-D
StephaneRodriguez wrote: If we forget UI or other application layers, and go down to the simplest types such like "int" and "char", then if we refer to the MSDN documentation is is clearly said that : - "int" is 32 bits : how does it cope with 64-bit oses ready this year? int will always be 32-bit in .NET; the full typename is System.Int32. In cases where you need a scalable value such as for pointers use IntPtr as that is what it is used for. On 32-bit platforms IntPtr will be 4 bytes and on 64-bit platforms it will be 8 bytes. If you need a 64 bit integer use C#s "long" or System.Int64. StephaneRodriguez wrote: - "char" is 16bits : how does it cope with the latest Unicode additions (I have read somewhere that 30 000 symbols have been added lately) ? Good point, and I have no idea; I assume we'll be stuck in the same situation as before and use codepages. StephaneRodriguez wrote: I have to argue that WindowsCE is with the .NET framework not even part of their strategy, as (as for what I have seen so far) no method implementation targets this platform. Its coming, last I knew the Compact Framework was still in beta. Quite a few people got to play with it back in the early Beta phases and they liked it. Unfortunately I only have a Palm 100 so I didn't get to have any fun :(( Smart Device Extensions and .NET Compact Framework Beta 1[^] StephaneRodriguez wrote: The Mobile internet toolkit looks like an application layer, not a framework layer. It provides server controls for ASP.NET which should render correctly given the devices support. Whether that is an application layer or a framework layer could be debated because it behaves as both in places. StephaneRodriguez wrote: In fact, what MS calls interoperable is on the one hand interoperable across their own Windows platforms (not between Sun,HP,S/390,...). Aside from not having an implementation of the CLI, what would stop a .NET console program from working on Sun, HP, S/390, etc? The CLI is the only part that Microsoft has said would be open for porting, the other technologies are more or less tied to Windows and kin thus it wouldn't make much sense to port them. Of course MS is pushing the usage of Windows Fo
-
StephaneRodriguez wrote: If we forget UI or other application layers, and go down to the simplest types such like "int" and "char", then if we refer to the MSDN documentation is is clearly said that : - "int" is 32 bits : how does it cope with 64-bit oses ready this year? int will always be 32-bit in .NET; the full typename is System.Int32. In cases where you need a scalable value such as for pointers use IntPtr as that is what it is used for. On 32-bit platforms IntPtr will be 4 bytes and on 64-bit platforms it will be 8 bytes. If you need a 64 bit integer use C#s "long" or System.Int64. StephaneRodriguez wrote: - "char" is 16bits : how does it cope with the latest Unicode additions (I have read somewhere that 30 000 symbols have been added lately) ? Good point, and I have no idea; I assume we'll be stuck in the same situation as before and use codepages. StephaneRodriguez wrote: I have to argue that WindowsCE is with the .NET framework not even part of their strategy, as (as for what I have seen so far) no method implementation targets this platform. Its coming, last I knew the Compact Framework was still in beta. Quite a few people got to play with it back in the early Beta phases and they liked it. Unfortunately I only have a Palm 100 so I didn't get to have any fun :(( Smart Device Extensions and .NET Compact Framework Beta 1[^] StephaneRodriguez wrote: The Mobile internet toolkit looks like an application layer, not a framework layer. It provides server controls for ASP.NET which should render correctly given the devices support. Whether that is an application layer or a framework layer could be debated because it behaves as both in places. StephaneRodriguez wrote: In fact, what MS calls interoperable is on the one hand interoperable across their own Windows platforms (not between Sun,HP,S/390,...). Aside from not having an implementation of the CLI, what would stop a .NET console program from working on Sun, HP, S/390, etc? The CLI is the only part that Microsoft has said would be open for porting, the other technologies are more or less tied to Windows and kin thus it wouldn't make much sense to port them. Of course MS is pushing the usage of Windows Fo
When you develop an entreprise product and big customers tell you to port a Windows app to Unix, your skills are speed and capabilities to port to this platform. Interoperability would normally mean that porting would be eased. I don't really see the point between this interoperability - from the real world - and the words interoperable that I see in MSDN doc. As long as you aren't in this process, the greatest way to ensure the capabilities to do it, is to stay informed. It is very hard these days to share marketing versus true technology behind the .Net strategy. Regarding DirectX, of course I wouldn't fight and say DirectX is not used. Of course, it is, and it's used by 99.99% of Windows games. I mean it is a failure because at the basis of the Game SDK, there should have been implementation which, for each feature, either were taking advantage of hardware, or were implementing it through software. Thanks to this paradigm, the DirectX was to be a tunnel were all games would run. May be slower if software was used instead of hardware. What happened to that ? I have bought games that I have never been able to run. At least 3 / 4 of game trials fall in this too.