Cannot compile madSecurity.pas in Delphi 2009
Cannot compile madSecurity.pas in Delphi 2009
Hi Mathias,
did you get my mails from Juli 12th, und July 19th (and July 29th)? I'm still waiting for an answer. I cannot compile madSecurity.pas in Delphi 2009. Could you please upload a madCollection with the correct madSecurity.pas that you use when compiling madCollection for D2009?
did you get my mails from Juli 12th, und July 19th (and July 29th)? I'm still waiting for an answer. I cannot compile madSecurity.pas in Delphi 2009. Could you please upload a madCollection with the correct madSecurity.pas that you use when compiling madCollection for D2009?
I don't seem to have received your emails. Strange. Try emailing to madshi (at) gmail (dot) com. madSecurity compiles fine in Delphi 2009 for me. The latest version is always available here:
http://madshi.net/madCollection.exe
What compilation error do you get?
http://madshi.net/madCollection.exe
What compilation error do you get?
I'm getting [DCC Error] madSecurity.pas(3107): E2100 Data type too large: exceeds 2 GB
at
I guess that is because TShareInfo50 is using char (instead of AnsiChar).
at
Code: Select all
type TAShareInfo50 = array [0..maxInt shr 6 - 1] of TShareInfo50;
Somehow I was afraid I was going to hear something like this. But, how do you explain that madTools.pas has osWin7 in included in TOsEnum? The digital signature of madCollection.exe is from Mittwoch, 22. Juli 2009 10:10:08. And as a precautios side-node: madSecurty.pas was created (not modified) on "Mittwoch, 29. Juli 2009, 11:39:17" on my harddisk. So the file really must have come from the latest installer.
Are you sure that you're including the correct file in the setup? If it makes a difference, I bought the complete madCollection a while ago.
Are you sure that you're including the correct file in the setup? If it makes a difference, I bought the complete madCollection a while ago.
Thank you, you actually found a bug in my automated installer creation. The PAS file you got is outdated. But still, the DCU file should be correct. Why are you trying to recompile the PAS file? The madCollection installer sets up madCollection in such a way that the PAS files are never recompiled, instead the precompiled DCUs are used. So if you're using the default installation configuration of madCollection, Delphi should not try to recompile the PAS file for you. Have you changed the configuration?
http://madshi.net/madCollectionBeta.exe
There will soon be a new official version with 2010 support, though.
There will soon be a new official version with 2010 support, though.
Converting everything to AnsiString was the quickest and safest way to make everything compile and work again without introducing all kinds of new bugs. madCollection uses loads of low level stuff and win32 APIs. Also win9x is still supported. Making sure that all this works fine with unicode strings would be a lot of work.
No idea why Embarcadero didn't offer a codepage compiler directive switch to toggle between forcing unicode and ansi strings. Converting PChar to PAnsiChar, Char to AnsiChar and String to AnsiString is also what I had to do with my various projects when converting from Delphi 7. Since Delphi 2009 I am careful to suffix any Win32 API calls I make that have unicode counterparts with "A" when I need to use Ansi, otherwise the compiler interprets this as calling the unicode version. I really prefer Delphi 7 even to this day...
--Iconic
--Iconic
I might be reading this wrong, but wouldn't that have meant that lots of components would have worked only if this (global) switch was set to ANSI?madshi wrote:Yeah, that would have made my life so much easier!
You do not need to support Win9x when UNICODE is defined, because Delphi 2009 applications won't run on Win9x.
For madsecurity.pas this means that all you would have needed to do is add a couple of {$IFNDEF UNICODE} windows 9x code {$ENDIF} and leave the rest of the file almost unchanged. And I'm almost sure that the WinNT Wide API functions work exactly like the ANSI functions. As a matter of fact, the exported ANSI functions are always wrappers around the Wide functions (there might be a few exceptions that confirm this rule). This might be different for undocumented stuff, but that seems to be relevant for Win9x only here.