Recent

Author Topic: Make Component work at design time  (Read 9486 times)

lesar

  • Newbie
  • Posts: 6
Make Component work at design time
« on: September 24, 2006, 01:28:31 am »
On Line 6925 of mine \ide\main.pp I have add this line in DoOpenProjectFile function:
Code: [Select]
SetCurrentDir(ExtractFilePath(AFilename));
I have a component that try to load a dll from local application dir at design time but without my line the current dir is the Lazarus dir, not the application dir.
After my change the component work fine at design time.

I have Look at Lazarus for only 5 hours and I don't know if my code is right.

Can help me?
(Sorry for my bad english)
best regards

Spike

  • New member
  • *
  • Posts: 9
Make Component work at design time
« Reply #1 on: September 24, 2006, 02:01:19 pm »
This might be a debugger issue, I'm not sure as I've never experienced this problem.
If this is trully bothering you, you can add the following line in the main program of your project (Project > View Source), right after the begin statement.

SetCurrentDir(ExtractFilePath(ParamStr(0)));

lesar

  • Newbie
  • Posts: 6
Resp
« Reply #2 on: September 24, 2006, 04:27:26 pm »
No if you put your line at the begin of the program this line will work at run time. The IDE program work at design time so we have to change the IDE to make component work fine at design time.

A component that try LoadLibrary on a library on the current folder have this problem:
At design time current folder is C:\Programmi\Lazarus
At Run time current folder is C:\Programmi\<application dir>

The component designer do not know C:\Programmi\<application dir>
so the component do a LoadLibrary(fbembed.dll) on relative path.

Quote from: "Spike"
This might be a debugger issue, I'm not sure as I've never experienced this problem.
If this is trully bothering you, you can add the following line in the main program of your project (Project > View Source), right after the begin statement.

SetCurrentDir(ExtractFilePath(ParamStr(0)));

JanH

  • Guest
RE: Resp
« Reply #3 on: September 25, 2006, 08:31:04 am »
how about to extend the system-variable PATH with path to your application dir?

lesar

  • Newbie
  • Posts: 6
Re: RE: Resp
« Reply #4 on: September 25, 2006, 10:14:59 am »
Quote from: "JanH"
how about to extend the system-variable PATH with path to your application dir?


Yes this will work but I do not think that is right. At run time the application current dir is the exe folder, at design time then component presume this is current directory. Ide have to simulate this beaviour.

If I write 100 applications i have to put 100 new variabiles in system-path.

The goal is not to make my app work but to make Lazarus work well.

Thank yoy for your responce

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2584
RE: Re: RE: Resp
« Reply #5 on: September 25, 2006, 12:23:20 pm »
Im not clear what you mean with designtime. Is your dll loaded while designing with the IDE or do you mean that the dll is loaded when debugging from the IDE.
In the first case, you should add the path to the dll to your windows path. That is how things are supposed to work on windows.
If you mean when debugging, chage the working directory in the run parameters.

Changing the working dir of an application is highly unwanted.
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

lesar

  • Newbie
  • Posts: 6
RE: Re: RE: Resp
« Reply #6 on: September 25, 2006, 01:18:24 pm »
When you execute your application build with Lazarus (file.exe) you are at run time
When you work on IDE Lazarus developing your application yoy are at design time
Quote

In the first case, you should add the path to the dll to your windows path

If I do for all dll my win path groove too mutch
In windows the first implicit folder to reseach a dll is the application folder. no need to add to the sistem path if a application bind a dll in his folder. That mean my file.exe have no problem at run time but at design time the component have a binding problem.

When Lazarus IDE active a project have to chenge the current dir to the project current dir

When Lazarus IDE show his property editor the current dir must be the project current dir and non the Lazzarus dir.
In this case the  compoment writer do not change their normal beaviour.

felipemdc

  • Administrator
  • Hero Member
  • *
  • Posts: 3538
Re: RE: Resp
« Reply #7 on: September 25, 2006, 02:21:46 pm »
Quote from: "lesar"
At run time the application current dir is the exe folder, at design time then component presume this is current directory. Ide have to simulate this beaviour.


You should be aware that this behavior only occurs on Microsoft Windows, and Lazarus runs on several other operating systems.

Similarly, if you code relies on getting the executable's directory, it will only work on Windows.

Quote
In windows the first implicit folder to reseach a dll is the application folder. no need to add to the sistem path if a application bind a dll in his folder. That mean my file.exe have no problem at run time but at design time the component have a binding problem.


Ok, I think I understand better now.

So, you are statically linking to the library?

I have a possible solution: Load the library dynamically, using LoadLibrary, GetProcAddress and FreeLibrary, from unit dynlibs:

http://www.freepascal.org/docs-html/rtl/dynlibs/index-5.html

Also, detect if your component is at design-time, and if so, do not load the library. Do you really need it's functionality at design-time?

lesar

  • Newbie
  • Posts: 6
RE: Re: RE: Resp
« Reply #8 on: September 28, 2006, 04:09:14 pm »
I think that <<the first implicit folder to reseach a dll is the application folder>> is true in posix too but this can is my fault.
I'am using UIB component. recompiling the Lazarus ide with my <<SetCurrentDir(ExtractFilePath(AFilename));>> now i can read the database structure a design time. UIB component try to load the connection database library using LoadLibrary & GetProcAddress but to use the database in embedded server mode the dll must be in application folder. The connection dll then try to load other dll in the current folder. if I set the LoadLibrary path to load dll then the dll try to load the otehr dll to the current dyrectory (Lazarus at design time)  but in lazarus dir there isen't his sub dll and thus fail. I think that this is not a problem only on windows system.

 

TinyPortal © 2005-2018