Something wrong when i close app access violation error

[eldonfsr]

I tried different ways to solve this problem i don't know why send me access error violation
just open and click on close or event if type information on EditDirectory  fiels .....
 

[eldonfsr]

Could be OnClose Event can't execute many instructions  or commands just i made change only on
close event and works..

Code: Pascal  [Select][+][-]

1. procedure TFormMain.FormClose(Sender: TObject; var CloseAction: TCloseAction);
2. begin
3.   BDConf.SaveToFile(GetCurrentdir+'\config.dat',dfBinary);
4. end;
5.  
6.  

   

[cdbc]

Hi
In the OnClose-event there's a CloseAction variable, that you need to set...:

Code: Pascal  [Select][+][-]

1. procedure TFormMain.FormClose(Sender: TObject; var CloseAction: TCloseAction);
2. begin
3.   BDConf.SaveToFile(GetCurrentdir+'\config.dat',dfBinary);
4.   { when you're done with your stuff, tell the FormMain, it's ok to close/free }
5.   CloseAction:= caFree; { ...or e.g.: caHide  }
6. end;
7.  

Regards Benny

[TRon]

1. You create a leak with   TLog:= TMemo.Create(nil);
2. Use DirectorySeparator instead of GetCurrentdir+'\config.dat'
3. using the formshow event to initialize your stuff is a bad habbit. It is done everytime the form is shown (so also every time a user 'activates' your application in order to show the main form).
4. The configuration file you saved can not be read again (stream read error)

Sorry as I did not try to locate your original issue.

[tetrastes]

3. using the formshow event to initialize your stuff is a bad habbit. It is done everytime the form is shown (so also every time a user 'activates' your application in order to show the main form).

Are you sure? May be I don't understand something, but...
Create the simplest app with form and OnShow event:

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormShow(Sender: TObject);
2. begin
3.     ShowMessage('FormShow is called');
4. end;

Message window is shown only once, when you start the app, whatever you do with it later (resize, minimize, bring to back under other window, bring to front...), message is not shown again.

[eldonfsr]

Thanks for your advanced, yes on show event i have many variables to define , for me is the place where i can initialize variables and  objects, could be better on active or what other event to initialize variables and objects ....

thanks for you time and advanced to me...

[dseligo]

3. using the formshow event to initialize your stuff is a bad habbit. It is done everytime the form is shown (so also every time a user 'activates' your application in order to show the main form).

Are you sure? May be I don't understand something, but...
Create the simplest app with form and OnShow event:

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormShow(Sender: TObject);
2. begin
3.     ShowMessage('FormShow is called');
4. end;

Message window is shown only once, when you start the app, whatever you do with it later (resize, minimize, bring to back under other window, bring to front...), message is not shown again.

Try clicking Button1 in attached project and you can see message window as many times as you like.
You can have many forms in your application and hide them and later show them again.

[tetrastes]

Try clicking Button1 in attached project and you can see message window as many times as you like.
You can have many forms in your application and hide them and later show them again.

Of course, but then you intentionally call Show in code, so you must know what are you doing.
It is not the same as

It is done everytime the form is shown (so also every time a user 'activates' your application in order to show the main form).

and my example shows that.

[dseligo]

Try clicking Button1 in attached project and you can see message window as many times as you like.
You can have many forms in your application and hide them and later show them again.

Of course, but then you intentionally call Show in code, so you must know what are you doing.
It is not the same as

It is done everytime the form is shown (so also every time a user 'activates' your application in order to show the main form).

and my example shows that.

And of course, that's a reason TRon wrote that it's a bad habit to do initializing in OnShow event.
You start with a simple app as you shown. After that you upgrade it (i.e. to intentionally call Show in code) and you are surprised why your app doesn't work as expected.

[tetrastes]

It's not a matter of habit, it's a matter of understanding what are you doing.
Even if you have a good habit not to do initializing in OnShow event, it won't save you from surprises if you don't think while upgrading your code. 

[TRon]

Are you sure? May be I don't understand something, but...

From what you wrote you understood me correctly 

I do not know the behaviour of each and every LCL widget for all available target platforms and how some desktop managers/tools manipulate their applications but perhaps you do ? So while it might work the way it does for you (there is no need for me to argue against your results as they are probably perfectly fine for your test) does not mean it works the same everywhere.

Additionally user dseligo is correct in that it is perhaps not a problem in sample and/or smaller applications but as soon as you start changing visibility of multiple forms you can get yourself into troubles.

Another thing that I dislike (and showed its colors in TS' example) is that I get errors even before a form has been made visible to me so that there is no feedback to the user whatsoever. Again perhaps TS presented the code for example-sake but in this particular case not very helpful and even disturbing in such a way that I could not be bothered to try locate the original issue (because I needed to correct this habit and remove other bugs first before being able to focus on the question being asked).

Another issue I have with using the main form's onshow event for initializing things is the time it might take to initialize things without presenting any feedback. Again, for example-sake it is perhaps good enough but really annoying for end-users and something you should never do for real production code.

But do note that most if not all of the issues I have with the onshow event are personal preferences (based on experience) so it is perfectly fine to disagree with anything that I wrote  If it all I do hope the reader could take some of the things that were written into consideration or at least think about it for a sec.

If you must initialize your application inside/at the Form's onshow event then make sure that it is only able to run once and that every error is accounted for.

[eldonfsr]

Well just comment we use segment or vent witch think as we get experience and also lazarus offer a few event i search some event trigger onafterload form or onload, onactive is trigger each time we refresh the form the we can initialize object...

i feel frustated on app i posted why if save tbufferdata without information open perfectly after that i can put information if you see examples of tbufferdata  save just save on close event and open app open with values, but for doesn't work...

[eljo]

Well just comment we use segment or vent witch think as we get experience and also lazarus offer a few event i search some event trigger onafterload form or onload, onactive is trigger each time we refresh the form the we can initialize object...

i feel frustated on app i posted why if save tbufferdata without information open perfectly after that i can put information if you see examples of tbufferdata  save just save on close event and open app open with values, but for doesn't work...

OnCreate is executed after the components are loaded (if I remember correctly) so use that for your initialization code.

[TRon]

Well just comment we use segment or vent witch think as we get experience and also lazarus offer a few event i search some event trigger onafterload form or onload, onactive is trigger each time we refresh the form the we can initialize object...

There is not a "one size fits all" solution that you seem to seek/look for.

It all depends on what it is you are trying to accomplish. My rule of thumb is to not ever let GUI related events be responsible for actual functional code (other then GUI related). In bigger projects I use a datamodule to initialize the application and provide feedback by using a progress dialog. For smaller projects like yours I would probably opt for either sending a custom message so that a custom method can be invoked, use an async call or use the onidle event (once, and only once).

i feel frustated on app i posted why if save tbufferdata without information open perfectly after that i can put information if you see examples of tbufferdata  save just save on close event and open app open with values, but for doesn't work...

I have (still) no idea what is causing the stream error when I test your program. A simple test (with FPC) shows that the handling of the configuration database with tbufdataset does work as intended. I need more time to try and figure out what is causing the stream error when used with Lazarus/your program.