there are two items of discussion in this post...

i've some converted code that expects INVALID_FILE_SIZE but this constant is not found... i did some digging and find INVALID_HANDLE_VALUE in LCLType but no other INVALID_* constants... so i go visit uncle google and i find something interesting...

[1]
in Lazarus LCLType : INVALID_HANDLE_VALUE = 0;
in synapse synaser : INVALID_HANDLE_VALUE = THandle(-1)

this link's message #10
http://cboard.cprogramming.com/windows-programming/21261-simple-question-again.html shows

#define INVALID_HANDLE_VALUE ((HANDLE)(LONG_PTR)-1)

which seems to be in line with what synapse shows... why does LCLType define it as 0 instead of -1? what's up with that?

[2]
in the above link, i also find the definition of INVALID_FILE_SIZE

#define INVALID_FILE_SIZE ((DWORD)0xFFFFFFFF)

i found several references and a few of those point to MSDN

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364955%28v=vs.85%29.aspx

why does this constant not exist in FPC or Lazarus? have i been looking in the wrong place or for the wrong thing? can we get this added to LCLType or should i convert it to use something else that already exists?

waldo kitty wrote

why does this constant not exist in FPC or Lazarus? have i been looking in the wrong place or for the wrong thing?

C:\repo\fpc\rtl\win\wininc>grep INVALID_HANDLE_VALUE *
defines.inc:     INVALID_HANDLE_VALUE = HANDLE(-1);

yes, that stems from windows.pp IIRC...

so why is that one different from the one in LCLType?

i was actually looking for INVALID_FILE_SIZE which i finally ended up defining as

   const
     INVALID_FILE_SIZE = DWORD($FFFFFFFF);

but i shouldn't have to do that if it were defined in LCLType with INVALID_HANDLE_VALUE??

the problem, and i guess i should have been more clear in my original post, is that the code i'm working with is converted from delphi to lazarus... as such, things like

   uses windows;

are replaced with

   uses LCLIntf, LCLType, LMessages;

this is important when one is wanting to convert a project to other platforms... it is very painful when one has never done delphi or winwhatever coding of any kind and is getting hit with winwhatever specific vars, consts, records and routines and has to spend hours hunting them down and trying to figure out how to replace or duplicate them :/

I changed the constant in LCLType accordingly.

http://wiki.lazarus.freepascal.org/Lazarus_1.2.0_release_notes#LCLType_INVALID_HANDLE_VALUE_now_Handle.28-1.29

Mattias

thanks, i think :)

what can we do about INVALID_FILE_SIZE?

   const
     INVALID_FILE_SIZE = DWORD($FFFFFFFF);

is the above correct? it would seem to be from what i can make out from MSDN and the various C code files i've found it defined in...

i kind of have to laugh because on place i read spoke of examples checking the result directly instead of using INVALID_FILE_SIZE and that this was not good coding practice because m$ might change the value of INVALID_FILE_SIZE at any time which would then break all of that code... i makes sense to me O:)

[...] thanks, i think :) what can we do about INVALID_FILE_SIZE?

What function returns that?

Mattias

while looking at the above link, i perused the other information on that page... it appear that this link

http://wiki.lazarus.freepascal.org/Lazarus_1.2.0_release_notes#TComponentPropertyEditor_behavior_was_changed

has left a word out... shouldn't it say

Effect: users of your component can *no* longer select components outside of the current form.

what is the purpose/meaning of INVALID_FILE_SIZE on first instance, I may ask...

Cheers, A.

i think it is a convenience constant... i searched uncle google for "INVALID_FILE_SIZE" and found these... i spent at least an hour early this morning rummaging to try to find out what i could about it...

https://www.google.com/search?num=100&q=MSDN+INVALID_FILE_SIZE then click on the "Search instead for MSDN INVALID_FILE_SIZE" link because the thing wants to take out the "_" chars :?

here are some of those links returned...

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364955%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364930%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/aa918933.aspx

http://msdn.microsoft.com/en-us/library/ee496424.aspx

this is a short discussions about a WINE and Shell32 patch...

http://www.winehq.org/pipermail/wine-devel/2005-November/041906.html

start here and see msgs #8-10 (at least)...

http://cboard.cprogramming.com/windows-programming/21261-simple-question-again.html

this link mentions windows.h as does the one above IIRC...

http://stackoverflow.com/questions/354329/anyone-know-where-a-good-windows-constant-list-lives

FWIW: the delphi code i'm wanting to convert uses it in numerous places... it seems to be a(nother) winwhatever const value...

all i can do is point to the links i just posted to mattias where it is defined and routines are shown with how to use it...

Amazing. I and several people have read this entry and no one noticed it. ;)
Fixed.

Mattias

all i can do is point to the links i just posted to mattias where it is defined and routines are shown with how to use it...

Uh... I just went through the first 2 or 3 links and the amount of crap I found is unbelievably enormous.

Why the hell should I consider 4 platforms on 2 architectures; then check the result whether I passed or not a NULL pointer to... ehm, well, just get the f***ing size of a file???? This, I am sorry, is out of my imagination scope.

God bless the one libc (end its ports, where possible, clean and working). full stop.

Cheers, A.

You can use "FileSizeUTF8" of unit LazFileUtils.

function FileSizeUtf8(const Filename: string): int64;

Negative result for failure.

God bless the one libc (end its ports, where possible, clean and working). full stop.

Mattias

i hear ya... i've done similar in many instances... our mind sees what it knows should be there...

Fixed.

i'm glad to at least be contributing something back to the project... no matter how small it is ;)

Using unsigned constants with int64 filesizes would classify files of exactly that size as invalid, while smaller or bigger files would be valid. This certainly is *not* what the coder had in mind, so that I'd suggest to inspect and fix all occurences of this (and similar) unsigned constants in user code.

IMO such unsigned constants should be used only in specific cases, e.g. with OS defined records containing part of an longer (int64) type. The FCL can use that constant in Win32 platform code, the LCL or user code never should use also doubt that the MS documentation is up to date whenever above constant is used with anything except struct fields of type DWORD. Even in 32 bit code *both* low/high parts of a 64 bit filesize must be checked for INVALID_FILE_SIZE, in order to determine a valid result.

DoDi

have you read the links i provided? exactly this situation is discussed in several of them ;)

the integral parts of any OS... while i've been coding for 30+ years, i've never done any GUI coding so the easier it is to make conversions happen, the better for all... IMHO, of course...

I also doubt that the MS documentation is up to date whenever above constant is used with anything except struct fields of type DWORD. Even in 32 bit code *both* low/high parts of a 64 bit filesize must be checked for INVALID_FILE_SIZE, in order to determine a valid result.

as i point out above, the documentation speaks specifically about this and it does give an alternative...

in specific to the code i'm looking to port, yes, the coders did intend this because that is how things were done at that time... 4Gig files were/are unheard of in that environment and still are today... there's no way we're going to be transferring 4Gig files... we won't even transfer those of 200+Meg in our hobby network... things may change in the future but until then, there are other technologies available for transferring such large files... especially if one is on dial-up making direct connections to the remote sites... i won't even mention the use of 9600 "baud" radio for the same ;)

i'm (finally) back to trying to poke this conversion thing with a sharp stick... i understand what you are saying in the above but i don't know how to "fix all occurrences of this (and similar) unsigned constants in user code."... i'm sure it is probably something easy that i'm not seeing... something like adding a sign ;)

   eg: INVALID_FILE_SIZE = DWORD(-1);

but how can i know if that will be what OS API functions send back? the above const is documented as shown above in the DWORD form so i already know that that particular instance from that particular API function will fail... since DWORD($FFFFFFFF) -1...

does not already exist? how can i tell my converted delphi project to use the FCL in addition to the LCL? right now when i look at the project inspector, the LCL is the only "required" package shown...

I also doubt that the MS documentation is up to date whenever above constant is used with anything except struct fields of type DWORD. Even in 32 bit code *both* low/high parts of a 64 bit filesize must be checked for INVALID_FILE_SIZE, in order to determine a valid result.

the documentation for the above const (which i linked to previously) talks about using a different OS API function for those instances where necessary...

Simple solution:

The INVALID_FILE_SIZE constant is used only inside Win32 RTL code, with API records or API functions returning exactly that type and value. This constant is not exported from the unit. Win32 specific user code, missing this constant value, has to be updated.

The user only gets platform-independent int64 filesizes, and here -1 or every negative value can indicate an error.

DoDi

The LCL uses the FCL, so your project too.

Mattias

has to be updated how? i don't know that part... but i guess part of the problem is also the conversion from a DPR to a LPR replaces everything with LCL specifics which i'm still trying to learn as well :? :/

The user only gets platform-independent int64 filesizes, and here -1 or every negative value can indicate an error.

i think i understand that... the problem is the conversion of DPR to LPR and what needs to be done after that to compile the project to even start any testing... perhaps this is due to not checking "support delphi"?? i dunno :(

waldo kitty wrote

converted from delphi to lazarus... as such, things like uses windows; are replaced with uses LCLIntf, LCLType, LMessages;

It is only replaced when "Cross-platform" is checked, although I believe the right way is to keep it checked also in your case.

i think i understand that... the problem is the conversion of DPR to LPR and what needs to be done after that to compile the project to even start any testing... perhaps this is due to not checking "support delphi"?? i dunno :(

You need to check "Support Delphi" only if you want to support Delphi with the same code.
Did you not test what the different options do?

You still study the Windows constants. Why? You should forget them and use the nice cross-platform functions instead. Mattias even gave you a correct answer for file sizes:
You can use "FileSizeUTF8" of unit LazFileUtils.

The converter already replaces many functions with their LCL counterpart. See "Function Replacements" in converter settings. If you find more functions to replace, please tell me.

Juha