GuiRichEdit.au3 - questions about: $tagCHARFORMAT and $tagCHARFORMAT2

[mLipok]

using GuiRichEdit.au3  I'm learning a little bit about DllCall and Structures.

By the way, I noticed some inconsistencies in the definition: 

$tagCHARFORMAT 

http://msdn.microsoft.com/en-us/library/windows/desktop/bb787881(v=vs.85).aspx

 

and 

$tagCHARFORMAT2

http://msdn.microsoft.com/en-us/library/windows/desktop/bb787883(v=vs.85).aspx

 

QUESTION 1: In this case, Is the mismatch between the

UDF: crCharColor
and

MSDN: crTextColor

may affect the operation of the script, which uses the structure.

QUESTION 2: In this case: how it can be done addiction, structure definitions $tagCHARFORMAT2 , depending on the controls version .

#if (_RICHEDIT_VER >= 0x0500)
  union {
    DWORD dwReserved;
    DWORD dwCookie;
  };
#else
  DWORD    dwReserved;
#endif

#if (_RICHEDIT_VER >= 0x0800)
  BYTE     bUnderlineColor;
#endif

[LarsJ]

Answer 1: If you by mismatch means that the names are different (crCharColor in AutoIt structure and crTextColor in C/C++ structure), then it doesn't matter, because the names are not part of the structure.

The names are only used to be able to reference the data fields in an easy way. In C/C++ you set and get the values of the data fields with dot notation (e.g. MyStruct.crTextColor). In AutoIt you use DllStructSetData and DllStructGetData.

When the code in the DLL is executed, the data fields of the structure are referenced directly by memory addresses.

If you by mismatch means that the crCharColor field in the AutoIt structure is defined as an int and the crTextColor field in the C/C++ structure is defined as a COLORREF = dword, then it doesn't matter either, because both data types allocates four bytes.

As long as you fill these four bytes with a proper RGB color value, the code in the DLL will work.

Answer 2: Note that the fields dwReserved/dwCookie in C/C++ and dwReserved in AutoIt in the first codebox, and bUnderlineColor in C/C++ and bReserved1 in AutoIt in the second codebox, are not used in the AutoIt UDF. If you want to use these fields, you have to implement the code yourself.

In C/C++ a union is a way to reference the same data field in the structure in different ways. The union in the codebox is allocating a single dword (not two dwords). In C/C++ you can refer to this data field in two ways: MyStruct.dwReserved and MyStruct.dwCookie. But it's the same data field.

(If you have written C/C++ code for the version before 0x0500, you can recompile the code for version 0x0500, without the need to replace all the dwReserved names with dwCookie. If you add new C/C++ code for version 0x0500, you can use the name dwCookie, which seems to be better than dwReserved.)

This means that the structure in the codebox is exactly the same before and after version 0x0500. In both cases a single dword is allocated.

In AutoIt you don't have to distinguish between versions before and after version 0x0500 for this field. In both cases you refer to the field with the name dwReserved. Note again, that dwReserved is not used in the AutoIt UDF.

If you have Rich Edit controls with _RICHEDIT_VER < 0x0800 (I don't know which Dll version 0x0800 matches), and the last field in the structure (bUnderlineColor in C/C++ and bReserved1 in AutoIt) is an issue, you can simply remove this field from the structure definition. Since bReserved1 is not used in the AutoIt UDF, the code will still work.

For Rich Edit controls where _RICHEDIT_VER >= 0x0800 you need bReserved1. Even if the field is not used. The size of the structure is stored in the first field: cbSize. If bReserved1 is missing, the value of this field will be one byte too small. This will cause an error.

Your structure definition for Rich Edit controls before and after 0x0800 should look like this:

Global $tagCHARFORMAT2 = $tagCHARFORMAT & ";word wWeight;short sSpacing;INT crBackColor;" & _
"dword lcid;dword dwReserved;short sStyle;word wKerning;byte bUnderlineType;byte bAnimation;byte bRevAuthor"
If $RICHEDIT_VER >= 0x0800 Then $tagCHARFORMAT2 &= ";byte bReserved1"

Since bReserved1 is not used in the AutoIt UDF, the code will work in both cases.

[mLipok]

Many thanks for such a wide lecture.
He was very informative.

btw.

If you have Rich Edit controls with _RICHEDIT_VER < 0x0800 (I don't know which Dll version 0x0800 matches)

 

here and here I find some usefull information:

 

This is defined as a Widows 8 feature (_RICHEDIT_VER >= 0x0800).

 

[LarsJ]

So the last field in $tagCHARFORMAT2 structure (bUnderlineColor/bReserved1) is only working on Windows 8. But do you have any examples where the last field is causing issues on XP, Vista or Win 7?

I think that $tagCHARFORMAT and $tagCHARFORMAT2 structures as defined in GuiRichEdit.au3 are working on all Windows versions. May be a few of the data fields are not working on older Windows versions. And may be a few of the data fields are not implemented in the UDF. But the two structures seems to be properly defined.

[mLipok]

I think that $tagCHARFORMAT and $tagCHARFORMAT2 structures as defined in GuiRichEdit.au3 are working on all Windows versions. May be a few of the data fields are not working on older Windows versions. And may be a few of the data fields are not implemented in the UDF. But the two structures seems to be properly defined.

 

I agree with you.

In the course of studying the MSDN documentation I was wondering what's new in the new Winodws systems.

I'll be on this issue a little work.

I do not have constant access to Windows 8, so I wonder if will be sufficient Win2012 Essential (I'll check it later)

For now, this week I will not have time to do it (today I took a few other tasks), but the EDIT case issue is on my list to check.

Even more so, in principle, this will be my first serious approach to the definition of structur in AutoIt.

Edited September 3, 2014 by mLipok