How to read from same dir as the *.app

[jimihendrix]

This should be a no brainer but it doesnt work

I have 2 files in the same directory eg

.test.app
file.html

in the code if I go
XXX.LoadFromFile( 'file.html' ); // theres an error cant find file!!!!!

XXX = HTMLviewer or Memo1.Lines

why on earth cant it find the file (this works in windows)
Is it a macos issue or a lazarus issue and more importantly whats the solution 

[Leledumbo]

why on earth cant it find the file (this works in windows)
Is it a macos issue or a lazarus issue and more importantly whats the solution

wiki has the answer

[jimihendrix]

cheers for that Leledumbo, I think I understand the issue now

Is it possible to emulate the method that windows uses
This application will only ever be run once + most often reside on a cd
i.e. storing it at /usr/share/app_name or /opt/app_name is both unnecessary and unwanted

OK Ive found what I need for the macOS
_NSGetExecutablePath()
but this is with C++
what is the equivalent lazarus function?

its not
GetCurrentDir()  which is in sysutils

I need something like
GetCurrentExecutableDir()

  Seems like such a simple thing is harder than I thought
Is it possible to call the above C++ function with lazarus?
eg like in c++ I can call C functions or asm pieces of code

[skalogryz]

You can try:

Code: [Select]

// application is the object available in Forms unit (LCL)
Appliction.ExeName
or

Code: [Select]

// Paramstr(0) might be not crossplatform or contain non full path
Paramstr(0)


[Wodzu]

  Seems like such a simple thing is harder than I thought
Is it possible to call the above C++ function with lazarus?
eg like in c++ I can call C functions or asm pieces of code

Of course you can jimi. You just need to provide your own headers for given dll.
And the asm code is called by wrapping assembly code with asm <your code> end; keywords.

[marcov]

  Seems like such a simple thing is harder than I thought
Is it possible to call the above C++ function with lazarus?
eg like in c++ I can call C functions or asm pieces of code

The test is usually if a _different_ c compiler can call the C++ code, then so can most Pascals.

Effectively this means it must be a plain C method (defined under extern C)

[jimihendrix]

oh cheers I think I have it
as skalogryz suggested Appliction.ExeName looks to be the bet

heres what I have which seems to work

namedir := LeftStr( Appliction.ExeName, Pos( 'blah.app', Appliction.ExeName ) - 1 );

[skalogryz]

heres what I have which seems to work

namedir := LeftStr( Appliction.ExeName, Pos( 'blah.app', Appliction.ExeName ) - 1 );

namedir := ExtractFileDir(Application.ExeName) ?

ExtractFileDir() is declared at SysUtils

[jimihendrix]

I dont think thats the same thing ( im on windows at the moment so cant check)
eg
Application.ExeName =A/B/C/D/.app/E/F/G

but what I want is A/B/C/D/
I think ExtractFileDir(Application.ExeName) returns more info (I havent tested this though)

but I know nothing, though I do know its a PITA 

[Jonas Maebe]

I dont think thats the same thing ( im on windows at the moment so cant check)
eg
Application.ExeName =A/B/C/D/.app/E/F/G

That is exactly the same as what _NSGetExecutablePath() would return (which is a C function, not a C++ function).

but what I want is A/B/C/D/
I think ExtractFileDir(Application.ExeName) returns more info (I havent tested this though)

On Mac OS X, you are normally not supposed to load any data from the same folder that contains your application. All files required by the application should be inside the application bundle itself (in the YourApp.app/Contents/Resources folder) or at fixed locations (~/Library/Application Support/YourApp/, /Library/Application Support/YourApp/, ...). As far as user-created files are concerned, it should be possible to put them anywhere the user wants. Exceptions to these rules are of course always possible depending on the circumstances, but those are the general guidelines.

However, it's of course trivial to construct the path to the folder containing the application bundle from the result of _NSGetExecutablePath()/Application.ExeName().

but I know nothing, though I do know its a PITA 

If you want to port to a new platform, you have to familiarize yourself first with the platform. It is not possible to properly develop for a system you don't know, regardless of any "Write once, compile anywhere" slogans.

[jimihendrix]

If you want to port to a new platform, you have to familiarize yourself first with the platform. It is not possible to properly develop for a system you don't know, regardless of any "Write once, compile anywhere" slogans.

Fair enuf I agree with what youre saying, in the past I have developed on linux I believe theres a few of my games floating out on the internet that run on that platform, so are aware of some issues (case sensitivity etc)

Though what I find strange is the inconsistency
eg
examples/turbopower_ipro/tpiproexample.lpi if I build this application it runs as expected on my powerpc + also windows
but if my mate builds it on his mac intel, + runs it he gets the message "index.html not found"

I would of thought there would be the same result on the mac-intel + the powerpc

Actually I suppose you could classify this as a bug in the examples as theyre not taking into account the different platform path reading methodology

[Jonas Maebe]

Though what I find strange is the inconsistency
eg
examples/turbopower_ipro/tpiproexample.lpi if I build this application it runs as expected on my powerpc + also windows
but if my mate builds it on his mac intel, + runs it he gets the message "index.html not found"

I would of thought there would be the same result on the mac-intel + the powerpc

The result will normally be same (barring endianess bugs). However, the "current directory" can vary depending on how the program is started. Maybe you are running it from inside Lazarus, while your friend may be running it by double-clicking it in the Finder.

Actually I suppose you could classify this as a bug in the examples as theyre not taking into account the different platform path reading methodology

That's certainly a problem. Very few people work on Mac support for Lazarus, and they have their hands full with the IDE and the LCL. It's very likely that most examples were only tested on Windows and/or Linux.

[jimihendrix]

ok cheers jmaebe, I would of thought mac support would be higher
as its currently undergoing a its the 'in platform' phase.
The reason I jumped on this in the first place cause I thought I could write/test on windows + then compile for mac, personally I would of been happy just pc only since Im well versed in win32etc + c
well anyways thanks

[Jonas Maebe]

ok cheers jmaebe, I would of thought mac support would be higher
as its currently undergoing a its the 'in platform' phase.

That's true. And the result is that a lot of people who know almost nothing about the Mac are coming to the platform. That does not automatically translate into new people with the ability to fix bugs; it results in many people that need a lot of support while they are unable to contribute much to the development itself.

The reason I jumped on this in the first place cause I thought I could write/test on windows + then compile for mac

Even with Java you can't do that if your program is somewhat complex. I think the only platforms that sort of can support such a development model are Flash and Silverlight (and even then only for the typical kind of mini-apps/games they are often used for).

[jimihendrix]

you wouldnt believe I ran into a similar issue again though this time on windows .net
return the path worked on all cases (normal directory,internet,usb drive etc) except for a single special case when the file had been burnt to cd rom on windows7 (winXP worked ok), in that case it would return an extra / at the end of the path!