Hi.
What is the preferred means to call SHBrowseForFolder using OE 64-bit?
The method that we have used for quite some time is crashing the OE session when executed in OE 64-bit:
PROCEDURE SHBrowseForFolder EXTERNAL "shell32":U : DEFINE INPUT PARAMETER lpbi AS LONG. DEFINE RETURN PARAMETER lpItemIDList AS LONG. END PROCEDURE.
Is there a .Net way that one should be using these days?
I notice that the OE ADE code is using CREATE 'Shell.Application' chServer. Is that the best way?
Thanks.
Would SYSTEM-DIALOG GET-DIR not suffice for some reason? This seems the easiest and most hands-off solution.
Go 21st century. Go .NET:
https://msdn.microsoft.com/en-us/library/system.windows.forms.folderbrowserdialog(v=vs.110).aspx
DEFINE VARIABLE oDialog AS System.Windows.Forms.FolderBrowserDialog NO-UNDO. DEFINE VARIABLE oDialogResult AS System.Windows.Forms.DialogResult NO-UNDO .
oDialog = NEW System.Windows.Forms.FolderBrowserDialog () .
// set additional options.
WAIT-FOR oDialog:ShowDialog() SET oDialogResult .
IF Progress.Util.EnumHelper:AreEqual (oDialogResult, System.Windows.Forms.DialogResult:Ok) THEN ....
Thanks.
We call other DLL procedures that function okay. Not sure why this one is being problematic.
Brian, yes it does to require the BROWSEINFO structure. No, we have no modified it as it did not appear that it would need to be modified. Out of curiousity, do you know what those changes may be?
Mike is right, it makes more sense to use .Net variant probably.
Tom, thanks for that tip.
Don't worry about it Brian. There are better alternatives. :) Thanks for the offer.
Would SYSTEM-DIALOG GET-DIR not suffice for some reason? This seems the easiest and most hands-off solution.
Yes, Ken. I think in prior releases it did not exist and we just never replaced our working solution. Using SYSTEM-DIALOG is much easier and does what we need.
[quote user="Jeff Ledbetter"]
Out of curiousity, do you know what those changes may be?
[/quote]
The OS memory layout is different between 32-bit and 64-bit, and any data you send to a dll must match that layout. Otherwise, you're effectively passing corrupt memory around and bad stuff happens.
- Byte allignment rules will be different between 32-bit and 64-bit.
- Pointers will be 8 bytes instead of 4, so variables holding them need to be converted to 64-bit . (That means changing your INTEGER and LONG declarations to INT64 *if running on 64-bit*.
See also http://knowledgebase.progress.com/articles/Article/P104543 and http://knowledgebase.progress.com/articles/Article/000044291
Not denying that :)
I just wanted to point out what you need to know if you don't have an alternative.
And if you really want to go 21st century, in 11.6 and up, you can simplify that last IF statement as:
IF oDialogResult = System.Windows.Forms.DialogResult:OK THEN ...
The AVM now recognizes Enums and will do the appropriate comparison on them... even .NET enums! So you no longer need to use the EnumHelper class.
Just saying :-)
P.S. (Sorry - I thought this would come after Mike Fechner's post way up top.) That IF statement replaces:
IF Progress.Util.EnumHelper:AreEqual (oDialogResult, System.Windows.Forms.DialogResult:Ok) THEN ...