Re: [fpc-pascal] specifying the relative path to a file that is located in the same folder as the application bundle?
So, as someone who only uses terminal apps written in fpc ( since ibuilder isn't really that usable and writing interface generating code is still beyond me despit trying for 4 years) Could you please post a copy of a code segment that shows how you performed this little marvel of finding files inside the app bundle? I've been trying (unsuccessfully) to imitate compiled programs by running interpreters on files located inside an app bundle. Thus far, I've had little success, but if you've gotten this working, then it's exactly what I was trying to do, and I sure could use your hard work. :-). On Feb 5, 2009, at 9:05 PM, Ken G. Brown wrote: Thanks a bunch for all the help! My legacy OS 9 app is now upgraded to OS X and working! It put up a hell of a fight but with all your help, the obstacles have been overcome. Awesome! Ken G. Brown At 9:51 PM +0100 2/5/09, Jonas Maebe apparently wrote: <> You have to allocate memory for it. Something like myBundlePathStr := getmem (CFStringGetMaximumSizeOfFileSystemRepresentation(bundlePathStr)); success := CFStringGetFileSystemRepresentation (bundlePathStr, myBundlePathStr, CFStringGetMaximumSizeOfFileSystemRepresentation(bundlePathStr)); When interfacing with C routines, you have to do the same things as if you were using C. And I notice that CFStringGetFileSystemRepresentation is only available for 10.4 and newer. What do i need to do instead if wanting to deploy to 10.3.9? Call CFStringGetCStringPtr and/or CFStringGetCStringPtr and tell it to convert to utf-8 (kCFStringEncodingUTF8). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: specifying the relative path to a file that is located in the same folder as the application bundle?
Travis Siegel wrote on vr, 06 feb 2009: On Feb 5, 2009, at 4:00 PM, Jonas Maebe wrote: On 05 Feb 2009, at 22:52, Paul Nicholls wrote: MyProgramFolder := ExtractFilePath(ParamStr(0)); This should hopefully get you the folder of the currently running program from within the program (at least under Win32 and Linux). That is completely OS (and sometimes OS-version) dependent, and should not be used if you want portable code (even on Linux it does not work under all circumstances). Ok, now I'm curious. Why doesn't this work? is it because of the way shells interpret currently running program? or is there something related to process ids or something? It is related to the fact that on Unix-like platforms the concept of *the* path to an executable does not exist (there can be multiple hard links all pointing to the same binary), an underlying directory can be renamed after a program has been started (so the path is no longer valid), the binary can be deleted while it is running (then it still exists on disk until the binary quits), etc. In a sense, this is no problem because on Unix-like platforms you are not supposed to use the fact where a binary is located in the first place. You should only use the directory where the user was when the binary was started (the present working directory), hard-coded paths (e.g., relative to the system root, and relative to the user's home directory), and paths inside configuration files stored in those directores. In case of bundled apps on Mac OS X this is different, which is why there are special API's in that case to resolve the location of the application bundle. If this doesn't work under all oses, is it something that could be fixed so it could work "properly"? No. We can make it work in many cases (which is what is currently done on Linux), but since no guarantees are offered by the OS, this is bound to break in rare cases or with new OS releases. For example, if a program is started using a symbol link, older Linux kernels used to report the file pointed to by this symbolic link. Newer kernels report the symbolic link itself. The result is that FPC-compiled programs relying on getting the actual binary location will break when run on newer kernels (until another kludge is added to also resolve these symbolic links, after which we can wait until the next change that breaks this system). And in no case the problems I mentioned at the start of this mail can be fully resolved. Also, if the OS only reports the command line as it was entered by the user (after resolving aliases), you have to start figuring out the used shell, the associated PATH, the used algorithm to determine which binary the shell will then pick, etc. I'm not all that familiar with internal os complexities, though I do seem to be drawing closer to that mark these days, but this seems to me to be an extremely important thing to know, and if fpc could be patched to provide this bit of info, shouldn't it be done? That has been done to a certain extent, but that does not mean that it is a good idea to rely on this information for anything but displaying information. For older Mac OS X releases, we'd have to follow the whole "do whatever we think the shell may have done"-routine. 10.5 reports "a" full path, but as mentioned it's unadvisable to rely on it being useful. How much troube would this be on an os like OSX for instance, where the app bundle isn't necessarily the same as the application itself? When using app bundles, use the bundle api's. When not using an app bundle, follow the standard Unix conventions and do not count in any way on being able to figure out where your binary is located. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] specifying the relative path to a file that is located in the same folder as the application bundle?
Basically from point of sale system running on Macintosh, I needed to pick up a
file with a known name located in the same folder as the application bundle,
and process it for printing in a custom format. This way it does not need the
file path hard coded in case it is different on the different computers. All
that is required os for the Prin.app to be located in the same folder as the
file. There are certainly other options.
Here is what I ended up with that is working, I'm open to suggestions for
improvement:
--
var
indexOfBundleNameStart : SInt32 = 0;
success : boolean = false;
mainBundle : CFBundleRef;
bundlePath : CFURLRef;
bundlePathStr : CFStringRef;
myBundlePathStr : pchar;
pathToPrintApp : Str255 = '';
const
printAppName : Str255 = 'Print.app';
begin
// Get the main bundle for the app
mainBundle := CFBundleGetMainBundle();
bundlePath := CFBundleCopyBundleURL(mainBundle);
bundlePathStr := CFURLCopyFileSystemPath (bundlePath,
kCFURLPOSIXPathStyle);
myBundlePathStr :=
getmem(CFStringGetMaximumSizeOfFileSystemRepresentation(bundlePathStr));
success := CFStringGetFileSystemRepresentation (bundlePathStr,
myBundlePathStr,
CFStringGetMaximumSizeOfFileSystemRepresentation(bundlePathStr));
if (success = true) then {get rid of 'Print.app' at the end of the path}
begin
pathToPrintApp := copy(myBundlePathStr, 1, Length(myBundlePathStr));
indexOfBundleNameStart := Pos(printAppName, pathToPrintApp);
delete(pathToPrintApp, indexOFBundleNameStart, Length(printAppName));
end;
// Writeln(stdout, myBundlePathStr);
// Writeln(stdout, 'Path to the app folder = ' + pathToPrintApp);
--
You would do something similar to pick up the paths to the other files of
interest within the app bundle package using whatever other routines necessary
as Jonas indicated.
Ken G. Brown
At 7:25 AM -0600 2/6/09, Travis Siegel apparently wrote:
>So, as someone who only uses terminal apps written in fpc ( since ibuilder
>isn't really that usable and writing interface generating code is still beyond
>me despit trying for 4 years) Could you please post a copy of a code segment
>that shows how you performed this little marvel of finding files inside the
>app bundle? I've been trying (unsuccessfully) to imitate compiled programs by
>running interpreters on files located inside an app bundle. Thus far, I've
>had little success, but if you've gotten this working, then it's exactly what
>I was trying to do, and I sure could use your hard work. :-).
>
>
>On Feb 5, 2009, at 9:05 PM, Ken G. Brown wrote:
>
>>Thanks a bunch for all the help!
>>My legacy OS 9 app is now upgraded to OS X and working!
>>It put up a hell of a fight but with all your help, the obstacles have been
>>overcome.
>>Awesome!
>>
>>Ken G. Brown
>>
>>At 9:51 PM +0100 2/5/09, Jonas Maebe apparently wrote:
>>><>
>>>You have to allocate memory for it. Something like
>>>
>>>myBundlePathStr:=getmem(CFStringGetMaximumSizeOfFileSystemRepresentation(bundlePathStr));
>>>success := CFStringGetFileSystemRepresentation (bundlePathStr,
>>>myBundlePathStr,
>>>CFStringGetMaximumSizeOfFileSystemRepresentation(bundlePathStr));
>>>
>>>When interfacing with C routines, you have to do the same things as if you
>>>were using C.
>>>
And I notice that CFStringGetFileSystemRepresentation is only available for
10.4 and newer. What do i need to do instead if wanting to deploy to 10.3.9?
>>>
>>>Call CFStringGetCStringPtr and/or CFStringGetCStringPtr and tell it to
>>>convert to utf-8 (kCFStringEncodingUTF8).
>>>
>>>
>>>Jonas
>>>___
>>>fpc-pascal maillist - fpc-pascal@lists.freepascal.org
>>>http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>>
>>___
>>fpc-pascal maillist - fpc-pascal@lists.freepascal.org
>>http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
>___
>fpc-pascal maillist - fpc-pascal@lists.freepascal.org
>http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] specifying the relative path to a file that is located in the same folder as the application bundle?
Ken G. Brown wrote: Basically from point of sale system running on Macintosh, I needed to pick up a file with a known name located in the same folder as the application bundle, and process it for printing in a custom format. This way it does not need the file path hard coded in case it is different on the different computers. But, does what Jonas said not apply here? Is the Mac a multi-user machine now? Even Windows has different users, hence c:\Documents and Settings\ If the Mac has different users, maybe the file to be printed/processed should go in the user's home directory? If the machine is to be used as a single POS terminal, then a standard location for the file might be appropriate (does the Mac have an equivalent to the Filesystem Hierarchy Standard in Linux?) I don't know the Mac, or your app, so this is probably all wrong, or inappropriate for you -- but I thought it worth mentioning because when I started using Linux it was not at all obvious to me that what Jonas described (the Unixy way of doing things) could work instead of the Windows way of putting files in the same directory as the .exe file. But, surprisingly, it does work quite well :) Frank ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: specifying the relative path to a file that is located in the same folder as the application bundle?
On Feb 5, 2009, at 4:00 PM, Jonas Maebe wrote: On 05 Feb 2009, at 22:52, Paul Nicholls wrote: MyProgramFolder := ExtractFilePath(ParamStr(0)); This should hopefully get you the folder of the currently running program from within the program (at least under Win32 and Linux). That is completely OS (and sometimes OS-version) dependent, and should not be used if you want portable code (even on Linux it does not work under all circumstances). Ok, now I'm curious. Why doesn't this work? is it because of the way shells interpret currently running program? or is there something related to process ids or something? If this doesn't work under all oses, is it something that could be fixed so it could work "properly"? I'm not all that familiar with internal os complexities, though I do seem to be drawing closer to that mark these days, but this seems to me to be an extremely important thing to know, and if fpc could be patched to provide this bit of info, shouldn't it be done? How much troube would this be on an os like OSX for instance, where the app bundle isn't necessarily the same as the application itself? I'm personally still using fpc to write terminal apps, because (as mentioned before) carbon apis aren't all that accessible for folks using voiceover, and since that's my main access to the os, I can't really use the ibuilder to design my interfaces, and the sample code for generating interface elements on the fly is spotty at best. So, for me, this isn't as much of an issue, but I certainly do have some ideas where this would be extremely useful, and I'm wondering how much trouble it would be to get the info of the app folder, as well as the actual executing path. So, feel free to pull out all the stops, spare me none of the gory details. I may not understand them all, but I sure would like to see them anyhow. (they will likely make sense later on). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] specifying the relative path to a file that is located in the same folder as the application bundle?
On 06 Feb 2009, at 17:05, Frank Peelo wrote: Ken G. Brown wrote: Basically from point of sale system running on Macintosh, I needed to pick up a file with a known name located in the same folder as the application bundle, and process it for printing in a custom format. This way it does not need the file path hard coded in case it is different on the different computers. But, does what Jonas said not apply here? No, because he's using a bundled application and not a command line app. In that case, conventions (and user expectations) are different. Is the Mac a multi-user machine now? Mac OS X Server 1.0 was released in 1999, and Mac OS X (client) 10.0 in 2001 on the desktop side (actually, even System 9 already had the concept of multiple users, but I don't remember anymore when it was released). But that's not really relevant here. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] specifying the relative path to a file that is located in the same folder as the application bundle?
At 4:05 PM + 2/6/09, Frank Peelo apparently wrote: >Ken G. Brown wrote: >>Basically from point of sale system running on Macintosh, I needed >>to pick up a file with a known name located in the same folder as >>the application bundle, and process it for printing in a custom >>format. This way it does not need the file path hard coded in case >>it is different on the different computers. > >But, does what Jonas said not apply here? Is the Mac a multi-user machine now? >Even Windows has different users, hence c:\Documents and Settings\ > >If the Mac has different users, maybe the file to be printed/processed should >go in the user's home directory? If the machine is to be used as a single POS >terminal, then a standard location for the file might be appropriate (does the >Mac have an equivalent to the Filesystem Hierarchy Standard in Linux?) The POS computer is always automatically booted into a single user that is always the same but not necessarily the same user on a different terminal. The information from the POS software for a custom invoice print format is presented in a file in the current folder of the POS software, I don't think there is a setting to control that but I'll look. So easiest for me right now is to put the custom print format output program there too, then the program works wherever the POS software is. Thx, Ken >I don't know the Mac, or your app, so this is probably all wrong, or >inappropriate for you -- but I thought it worth mentioning because when I >started using Linux it was not at all obvious to me that what Jonas described >(the Unixy way of doing things) could work instead of the Windows way of >putting files in the same directory as the .exe file. But, surprisingly, it >does work quite well :) > >Frank > >___ >fpc-pascal maillist - fpc-pascal@lists.freepascal.org >http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Error: Identifier not found "try"
Hello,
The simple program below fails when compiling (2.2.2-8 and 2.2.4rc1) :
program TEST_TRY;
uses SysUtils, strutils;
Function IsNumber(ValueToCheck:string):boolean;
begin
try
StrToInt(ValueToCheck);
IsNumber := true;
except
IsNumber := false;
end;
end;
begin
If IsNumber('123') then
writeln('this is a number');
end.
t...@linux$ fpc Test_Try.pas
Free Pascal Compiler version 2.2.4rc1 [2009/01/25] for i386
Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Linux for i386
Compiling Test_Try.pas
Test_Try.pas(8,4) Error: Identifier not found "try"
Test_Try.pas(8,4) Fatal: Syntax error, ";" expected but "identifier
STRTOINT" found
Fatal: Compilation aborted
Error: /usr/bin/ppc386 returned an error exitcode (normal if you did not
specify a source file to be compiled)
Did I miss something obvious ?
Thanks
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error: Identifier not found "try"
On 06 Feb 2009, at 21:31, T.Guilleminot wrote: t...@linux$ fpc Test_Try.pas Free Pascal Compiler version 2.2.4rc1 [2009/01/25] for i386 Copyright (c) 1993-2008 by Florian Klaempfl Target OS: Linux for i386 Compiling Test_Try.pas Test_Try.pas(8,4) Error: Identifier not found "try" Test_Try.pas(8,4) Fatal: Syntax error, ";" expected but "identifier STRTOINT" found Fatal: Compilation aborted Error: /usr/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled) Did I miss something obvious ? Yes, you have to activate the Delphi or ObjFPC compilation mode. You may want to read http://wiki.lazarus.freepascal.org/Code_Conversion_Guide if you are coming from Delphi or Kylix (e.g., this issue is mentioned here: http://wiki.lazarus.freepascal.org/Code_Conversion_Guide#Selecting_the_right_compiler_mode ) Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
