PDA

View Full Version : Problem Resolution



Edgard
4-Dec-2019, 10:37 AM
Hi Harm,

I generated distinct packages, keeping the same class name (for compatibility).

13302
In the future, will the studio control this and disregard .pkg (32 bits) if I parameterize the 64 or 32 bit combo?

The case of MSOUTL.pkg, to me, is stranger, because I did not generate on both platforms.

I am sending these packages if you want to test.

Best Regards,

Edgard

starzen
4-Dec-2019, 12:16 PM
+1

we have been having an issue with this for a long time

Harm Wibier
5-Dec-2019, 05:13 AM
Did you notice that both packages are exactly the same (except for the comment with the file path)? That means that this vendor succeeded in using the proper types in his definition to allow both the 32-bit and 64-bit API to be identical. That is the ideal scenario as here you don't need the #IFDEF and duplicate packages at all.

The point raised is a valid point. CDS (the studio code parser) does not take the Is$WIN64 symbol into account. It is capable of handling conditionals like this, you can actually tell it about them in your workspace properties. Adding Is$WIN64 to the list of conditionals actually makes the errors go away. We'll see if we can do something about this, for now adding the conditional manually is the workaround.

13312

Edgard
5-Dec-2019, 10:11 AM
Hi Harm,

I think I understood,

If psProgId is the same at 32 and 64, I don't need to duplicate the packages. Right ?

There is really a difference when I am using the trial vs. license:

13314

As I currently do not have the 64 license, I tested with the trial version.

Ok, you will try to improve the behavior so that this case is resolved because it is just an inconvenient warning.

I believe your version has been improved because I keep getting criticism in MSOUTL.PKG.

13315

This is the typical example you mentioned, where the same package works at 32 and 64 bits.

In particular, I am really enjoying the versatility of working with the 32-bit and 64-bit DF20 switch and using it in conjunction with DF19.1.

We have to be careful to make the change in DF19.1, because by writing in DF20 and opening in DF19.1 special characters are replaced, DF20 reads and interprets DF19.1, but not the other way around (Language: Portuguese).

It's a matter of time and tightening screws!

Regards,

wila
7-Dec-2019, 03:05 PM
Just saw another side effect of this and here it might be even more confusing.

I have code that compiles in both DF19.1 as well as DF20.0

So for wrapping the Windows API I have these declarations:


#IF (!@ < 200)
Use vWin32fhA.pkg // WinAPI ANSI legacy interface
#ELSE
Use vWin32fhW.pkg // WinAPI Unicode version
#ENDIF


Where vWin32fhA.pkg includes the vWin32fhA.h file that has this struct declaration ->


Struct tvWin32FindData
Dword dwFileAttributes
Dword ftCreationLowDateTime
Dword ftCreationHighDateTime
dword ftLastAccessLowDateTime
Dword ftLastAccessHighDateTime
Dword ftLastWriteLowDateTime
Dword ftLastWriteHighDateTime
Dword nFileSizeHigh
Dword nFileSizeLow
Dword dwReserved0
Dword dwReserved1
UChar[vMax_Path] cFileName
UChar[14] cAlternateFileName
End_Struct


and the wide version alternative in vWin32fhW.h looks like this:


Struct tvWin32FindData
Dword dwFileAttributes
Dword ftCreationLowDateTime
Dword ftCreationHighDateTime
dword ftLastAccessLowDateTime
Dword ftLastAccessHighDateTime
Dword ftLastWriteLowDateTime
Dword ftLastWriteHighDateTime
Dword nFileSizeHigh
Dword nFileSizeLow
Dword dwReserved0
Dword dwReserved1
Short[vMax_Path] cFileName
Short[14] cAlternateFileName
End_Struct


While debugging I issued a "Goto definition" on the following line:


//
Procedure LoadBuffer String sSearchPath
tvWin32FindData FindData


and this brings up the ansi version of the declaration and not the wide version even while I _am_ compiling with DataFlex 20.0.

If you're debugging and not aware of this particular pecularity then it is super weird that the following code does not work...



Move (UCharArrayToString(FindData.cAlternateFileName)) to sAlternateFileName

Because well.. it's not a UChar array at all, it's an array of Shorts!

FWIW you fix that like this:


#IF (!@ < 200)
Move (UCharArrayToString(FindData.cAlternateFileName)) to sAlternateFileName
#ELSE
Move (PointerToWstring(AddressOf(FindData.cAlternateFil eName))) to sAlternateFileName
#ENDIF


FWIW, it might be a good idea to add "UCharArrayToString" invocations in your code to the "to be inspected list" for DataFlex 20, especially when it is data that comes from interacting with the Windows API.

--
Wil

Stephen W. Meeley
20-Dec-2019, 10:34 AM
To all,

In Technology Preview 2, the Studio sets the Is$Win64 conditional upon opening the project, upon creating a project and upon switching between 32/64-bit. When switching, the code must be re-parsed so depending on the project this may take some time.

Edgard
13-Jan-2020, 08:19 AM
Grateful for the attention.