Converting MSDN C++ functions to MQL4 functions! WINAPI, User32.dll... - page 3

New comment
 
Stanislav Korotky:

You should do something like this.

cursor.mqh

cursor.mq4

It works in the sense that correct handles are received.

The cursor is not displayed though, because the terminal is setting it on every mouse event according to its internal rules, hense your custom cursor is instantly overriden. So, i think, your requirement is not doable. You should reconsider your task and find another approach for what you want to achieve.


Thank you very much for your answer.


I couldn't make it work. I'm not sure what I am doing wrong again because there was no error when I compiled it yet the EA doesn't get attached once I attach it! I tried to compile it as a script but there was an error.

Should I replace the Image parameter with the path to the image cursor ?

 
TomQL:

Thank you very much for your answer.

I couldn't make it work. I'm not sure what I am doing wrong again because there was no error when I compiled it yet the EA doesn't get attached once I attach it! I tried to compile it as a script but there was an error.

Should I replace the Image parameter with the path to the image cursor ?

Of course you should use actual path to your image. But as I said the approach with cursor will most likely not work because the terminal controls the cursor. For specific errors you have you should post exact messages, codelines, etc if you want an assistance.

I suggest you to describe exact task which you want to perform by cursor change. Then another solution can be advised. For example, if it's about some progress indication - it's better to use on-chart objects.

 
JC:

...

Since this forum is now a sub-area of mql5.com, I'll mention that MT5 introduces major headaches in this area because, in a 64-bit application, many Windows handles become 8 bytes long rather than 4. You need separate DLL imports for MQL5 code depending on whether it is running as 32-bit or 64-bit. And therefore you potentially need separate paths of run-time execution around each DLL call. The socket code mentioned above provides an example of this, basically having two different paths of execution in many areas for 64-bit MQL5 vs 32-bit MQL5 or MQL4.


Actually I never encountered problems with the pointer/handle interpretation in calls to Winapi. Windows resolves the proper path automatically and all I need is specifying the handle length in the beginning of imports.

 
Ex Ovo Omnia:

Actually I never encountered problems with the pointer/handle interpretation in calls to Winapi. Windows resolves the proper path automatically and all I need is specifying the handle length in the beginning of imports.

Yes, but the handle length varies for 64-bit applications versus 32-bit applications (and thus for 64-bit MQL5 versus 32-bit MQL5, or MQL4). In many cases, you can get away with passing 4-byte values to a 64-bit O/S but, in 64-bit Windows, things like window handles, sockets etc are defined as 8 bytes. Therefore, to be properly compliant with the Windows API, and fully future-proofed, you need to do things like the following:

#import "user32.dll"
   int ShowWindow(int, int); // For 32-bit
   int ShowWindow(long, int); // For 64-bit
#import

...

if (TerminalInfoInteger(TERMINAL_X64)) {
   long handle = ChartGetInteger(0, CHART_WINDOW_HANDLE);
   ShowWindow(handle, 1); // Force MQL to use the 64-bit import by specifying long parameter
} else {
   int handle = (int)ChartGetInteger(0, CHART_WINDOW_HANDLE);
   ShowWindow(handle, 1); // Force MQL to use the 32-bit import by specifying int parameter
}

Failure to do this sort of thing may work now - will probably work now in most cases, except where Windows expects or returns a raw memory pointer rather than a managed handle - but could theoretically stop working in any future Windows update from today onwards.

Going back to my earlier socket example, socket handles are, in effect, always only 4 bytes even on x64 (and very likely to remain so), and therefore you can get away with using an int import in MQL because the value will get converted from 4 bytes to 8 bytes by the all the code between you and the Windows API. However, something like the hostent structure has different sizes on x86 and x64, because all the pointers within it become 8 bytes long on x64.
 

JC:

Yes, but the handle length varies for 64-bit applications versus 32-bit applications (and thus for 64-bit MQL5 versus 32-bit MQL5, or MQL4). In many cases, you can get away with passing 4-byte values to a 64-bit O/S but, in 64-bit Windows, things like window handles, sockets etc are defined as 8 bytes. Therefore, to be properly compliant with the Windows API, and fully future-proofed, you need to do things like the following:

Failure to do this sort of thing may work now - will probably work now in most cases, except where Windows expects or returns a raw memory pointer rather than a managed handle - but could stop working in any future Windows update from today onwards.


Opps, I am quite a noob with this C-like advanced design, and I do not know what managed handle or raw pointer are. All I am saying I do not have problems with including my MQL4 winapi imports into the MQL5 program, they work without change. All I am doing more, is specifying the pointer length like below and keeping the imports from MQL4 unchanged:


#define IS_64_SYSTEM

.....

#ifdef IS_64_SYSTEM
   #define POINTER_HOLDER long
#else 
   #define POINTER_HOLDER int
#endif 

#define HANDLE POINTER_HOLDER
#define HWND HANDLE
#define UINT uint
#define _In_ const
#define WINAPI

#import "user32.dll"

HWND WINAPI GetWindow(
  _In_ HWND hWnd,
  _In_ UINT uCmd
);
#import
 
Ex Ovo Omnia:

All I am doing more, is specifying the pointer length like below and keeping the imports from MQL4 unchanged:

That will work fine, but doesn't it mean that you have to compile separate versions of the .ex5 file for 32-bit and 64-bit computers?

It seems like you must need one version of the .ex5 with IS_64_SYSTEM, for use on 64-bit Windows, and a separate .ex5 file without IS_64_SYSTEM, for use on 32-bit.

 

For your information, MT5 32-bits has no future.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Версия программы 32 или 64

Renat Fatkhullin, 2017.02.20 19:19

We are fully focused on the complete testing of 32-bit versions of MT5 programs:

  • Since July 1, 2017 we will stop releasing 32-bit versions of management terminals
  • From July 1, 2017 we will begin actively demanding to switch all 32 bit versions launched in a 64 bit environment
  • From January 1, 2018 completely stop support for all operating systems below Windows 7
  • Since January 1, 2018, we will stop updating 32-bit versions of client terminals


 
JC:

That will work fine, but doesn't it mean that you have to compile separate versions of the .ex5 file for 32-bit and 64-bit computers?

It seems like you must need one version of the .ex5 with IS_64_SYSTEM, for use on 64-bit Windows, and a separate .ex5 file without IS_64_SYSTEM, for use on 32-bit.


Definitively.  I have both MT5 installed for testing.

 
TomQL:

HCURSOR Type.


Because I'd like to change the shape of the cursor once I am dragging a Rectangle or Canvas. 


 
Bburey:
Hi I think the problem is security where the function is trying to load the cursor from a file. I’m not sure if there is an equivalent function where you can load from memory and just place the cursor file inside the DLL. If I have chance today I will take a look. 


123
New comment
Reason: