Global variables - how? lazarus / 8-Other ---------------------------------------------------------------------- JanRoza · 2008-06-06 12:03 Hi I must have a blackout but I can't figure out how to declare a variable in my Main unit which should also be available in another unit called from the Main unit. I thought that if I declared that variable (or constant) before the Implementation it would be available troughout my program, but I keep getting a compile error in the called unit saying 'identifier not found'. In the main unit I have coded:  Code: [Select] const     strIniPath: string = 'c:\ini';     .....     .....   private     { private declarations }   public     { public declarations }     procedure ShowURL(URL : String);   end; var   frmMain: TfrmMain; implementation in the main unit I open a new form with Code: [Select]        frmWarning := TfrmWarning.Create(Self);        frmWarning.Showmodal;        frmWarning.Release;        frmWarning := nil; In the Warning unit I try to use that strIniPath variable again via Code: [Select]   strIniFile := strIniPath + '\Icm.ini'; What am I doing wrong? ---------------------------------------------------------------------- Phil · 2008-06-06 13:40 Quote from: "JanRoza"Hi I must have a blackout but I can't figure out how to declare a variable in my Main unit which should also be available in another unit called from the Main unit. I thought that if I declared that variable (or constant) before the Implementation it would be available troughout my program, but I keep getting a compile error in the called unit saying 'identifier not found'. In the main unit I have coded:  Code: [Select] const     strIniPath: string = 'c:\ini';     .....     .....   private     { private declarations }   public     { public declarations }     procedure ShowURL(URL : String);   end; var   frmMain: TfrmMain; implementation in the main unit I open a new form with Code: [Select]        frmWarning := TfrmWarning.Create(Self);        frmWarning.Showmodal;        frmWarning.Release;        frmWarning := nil; In the Warning unit I try to use that strIniPath variable again via Code: [Select]   strIniFile := strIniPath + '\Icm.ini'; What am I doing wrong? Add uses Main to the implementation section of your other unit. Thanks. -Phil ---------------------------------------------------------------------- Leledumbo · 2008-06-06 14:00 I don't really get it, you mean you have strIniFile declared in Main unit, then you have another unit called Warning which also need to access this variable (or to be precise, typed constant)? If so, just add Main to Warning's uses clause. Be careful, if Main unit uses type declaration from Warning unit (in this case, I guess TfrmWarning), you can't have Main in uses clause of Warning unit's interface section because it will cause circular unit reference. You can only have it in implementation section. ---------------------------------------------------------------------- JanRoza · 2008-06-06 14:59 Leledumbo you're correct. My Main unit checks to see if the program already has an ini file and if not creates it. Further on during starrtup it will show a warning screen to attend users to some prerequisites ("program such and so should not be running"). But it would get annoying to a user if this warning shows up everytime they use my program so in the Warning form there's a checkbox where the user can disable the warning screen. So the Warning unit needs to update the ini file of which the Main unit already has determined its path. Of course I could use the same coding again in the Warning unit and let that unit figure out the location of the ini file again, but why should I if the Main has already just done this task. I also tried a different route by putting a hidden edit field on the Main form and referring to this fields text property from the Warning unit but this edit field is unknown to the Warning form. So yes, the dilemma is Main call Warning but Warning needs a variable from Main so a circular reference could occur. Any ideas how to solve a problem like this. An alternative might be to let the Main check for the running of the other program but I don't know how to check if another program is running. Any suggestions are welcome. On another note: I always wondered about your forum name 'leledumbo', my first thoughts are that it's a african name but then there might be a more simple answer  :lol: ---------------------------------------------------------------------- Phil · 2008-06-06 18:29 Quote from: "JanRoza"I also tried a different route by putting a hidden edit field on the Main form and referring to this fields text property from the Warning unit but this edit field is unknown to the Warning form. So yes, the dilemma is Main call Warning but Warning needs a variable from Main so a circular reference could occur. Any ideas how to solve a problem like this. If you include the main form's unit in the implementation section of your other unit, you can reference the main form's properties and methods using Main.someproperty and not have any circular references. On Windows, you can determine if another program is running using the FindWindow Windows API function. Thanks. -Phil ---------------------------------------------------------------------- JanRoza · 2008-06-06 22:14 Thanks Phil, You're right I had the use at the top of my unit, putting it in the implementation section solved that part. For the running programs I will look into the FindWindow API as that seems to be a better way. Jan ---------------------------------------------------------------------- JanRoza · 2008-06-07 23:59 Phil, Your tip on using the FindWindows API was gold! Found a nice and complete example for usi FindWindows on Swiss Delphi Center: http://www.swissdelphicenter.ch/torry/showcode.php?id=327 Maybe this will help others too.   Jan ---------------------------------------------------------------------- Leledumbo · 2008-06-09 08:17 Putting it on implementation section is indeed one of the possible solution. But in the view of a design, it's better to put it in separate unit. That way, your project would be more maintainable. leledumbo: Indonesian name for Clarias gariepinus (it's because of my moustache, they're longer at the edge, just like the fish's) ---------------------------------------------------------------------- JanRoza · 2008-06-09 08:35 Thanks for the explanation Leledumbo. You're absolutely right about maintainablility. And about the name, never knew the fish but seeing its picture on Google and get your meaning  :lol: Jan