Storing object properties

[Edson]

And from properties you can go to variables. Although that is a bit redundant. Seems you are not aware of TDataModule and storing your (global) settings in there using properties ? Whether or not you associate those properties to anything else is up to yourself.

Maybe You don't understand. What I need to do is:

Disk <---> Variables <---> Visual Component

Because I use Variables to stores global properties of my application. The "disk" part, is need to save their values, and the "Visual Component" is needed to edit/change their values.

I don't store global properties of my application in components. They are used only for edition. And not all these properties are editable. So in some cases I just need:

Disk <---> Variables

And that's what my library do (both cases).

[molly]

Maybe You don't understand.

Although (sorry to say) i haven't given miConfig a proper look, i do know what you meant 

What I need to do is:

What you are doing is restricting your code into a particular solution because you believe that is the only solution that is correct for your program(s). There we disagree 

I don't store global properties of my application in components. They are used only for edition. And not all these properties are editable. So in some cases I just need:

I also use them for editing purposes. Using a component is only convenient because it allows to 'map' the properties in the visual editor. You can perfectly do without components, but that requires you to manually add them (which can be automated though).

And that's what my library do.

Yes, and all i say is that your solution is imho overcomplicated and rigid for larger projects. I simply fail to understand why you would store your settings into separate variables, especially when dealing with a oop language.

On the same note you would not have to use something like TXMLPropStorage but simply stream the components that 'stores' your settings.

[Edson]

What you are doing is restricting your code into a particular solution because you believe that is the only solution that is correct for your program(s). There we disagree 

No. Don't missunderstand me. I don't believe it's the only. It's just what I use and make my life easy. 

Yes, and all i say is that your solution is imho overcomplicated and rigid for larger projects. I simply fail to understand why you would store your settings into separate variables, especially when dealing with a oop language.

That variables can be fields of an object (singleton or not).
Maybe it's overcomplicated at first sight  , but once you use it's very simple and I've used in several projects, including:

https://github.com/t-edson/Tito-s-Terminal
https://github.com/t-edson/PicPas
https://github.com/t-edson/CiberPlex
https://github.com/t-edson/TitoCad
https://github.com/t-edson/Minimat

Some of them, having many thousands of lines of code. And it's easy to create/delete new global properties and the respective edition controls.

but simply stream the components that 'stores' your settings.

Because I don't store settings in components  . I think it's stupid, rigid, inefficient, and a bad design  . I just use components when settings are editable.  But anyway it's just my opinion  I could be wrong.

[PatBayford]

It has always been a source of deep regret for me that Delphi, and, therefore, Lazarus have not implemented genuine object serialization. After all, the basic principles have always been there, for storing/loading  components. It seems like a gross oversight not to realize that real-world applications need to store and load DATA. I have played with several different methods both in Delphi and Lazarus - none are completely satisfactory. Why, oh why did Borland/Embarcadero never properly document TFiler, TWriter and TReader? Not to mention the mess that is the RTTI documentation.
This op's problem would be trivial in something like Ruby - define the object, then serialize it to disk using Jason, plain text, XML or, even perish the thought binary! Sadly, I find the background programming concepts too difficult for an old geezer like me!!

[mangakissa]

Guys, Read the first topic again. It has nothing to do with the object properties of a component.

I'm looking for a shorter way to store user preferences, in this exemple I must define a setter to each property in order to save it's value
hat I am understandable (for example in PHP I would have used magic methods __set). Do someone know a better way ?

Kembill has some values in his progrem to save it by user / desktop. These values has to be saved and loaded again. XML is nice.

@Kimbel
Yes, if you want values called by properties you have to create several properties to call. But there are different ways to accomplish it.
This is one example with tstringlist:

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

1. type TSomething = class
2.   fMyValues : TStringlist;
3.   public
4.     constructor Create;
5.     destructor Destroy; override;
6.     function get (const aValue : string) : string;
7.     procedure put (const aValue: string);
8. end;
9.  
10. implementation
11.  
12. { TSomething }
13.  
14. constructor TSomething.Create;
15. begin
16.   fMyValues := TStringlist.create;
17.   fMyValues.LoadFromFile('myproperties.txt');
18. end;
19.  
20. destructor TSomething.Destroy;
21. begin
22.   fMyValues.SaveToFile('myproperties.txt');
23.   fMyValues.Free;
24.   inherited;
25. end;
26.  
27. function TSomething.get(const aValue: string): string;
28. begin
29.   result := fMyValues.Values[aValue];
30. end;
31.  
32. procedure TSomething.put(const aValue: string);
33. begin
34.   fMyValues.Values[aValue] := aValue;
35.   //create a procedure to save data to file
36. end;
37.  
38. end.
39.  

My favorite is tBufdataset with own functions (see attachment).

As develooper you can do what you want as long as the user doesn't see it

[KemBill]

Guys, Read the first topic again. It has nothing to do with the object properties of a component.

I'm looking for a shorter way to store user preferences, in this exemple I must define a setter to each property in order to save it's value
hat I am understandable (for example in PHP I would have used magic methods __set). Do someone know a better way ?

Kembill has some values in his progrem to save it by user / desktop. These values has to be saved and loaded again. XML is nice.

@Kimbel
Yes, if you want values called by properties you have to create several properties to call. But there are different ways to accomplish it.
This is one example with tstringlist:

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

1. type TSomething = class
2.   fMyValues : TStringlist;
3.   public
4.     constructor Create;
5.     destructor Destroy; override;
6.     function get (const aValue : string) : string;
7.     procedure put (const aValue: string);
8. end;
9.  
10. implementation
11.  
12. { TSomething }
13.  
14. constructor TSomething.Create;
15. begin
16.   fMyValues := TStringlist.create;
17.   fMyValues.LoadFromFile('myproperties.txt');
18. end;
19.  
20. destructor TSomething.Destroy;
21. begin
22.   fMyValues.SaveToFile('myproperties.txt');
23.   fMyValues.Free;
24.   inherited;
25. end;
26.  
27. function TSomething.get(const aValue: string): string;
28. begin
29.   result := fMyValues.Values[aValue];
30. end;
31.  
32. procedure TSomething.put(const aValue: string);
33. begin
34.   fMyValues.Values[aValue] := aValue;
35.   //create a procedure to save data to file
36. end;
37.  
38. end.
39.  

My favorite is tBufdataset with own functions (see attachment).

As develooper you can do what you want as long as the user doesn't see it

TSomething is now a kind of associative array 

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

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils;
9.  
10. type
11.   { TSomething }
12.  
13.   TSomething = class(TObject)
14.   private
15.     fMyValues: TStringList;
16.     function ReadProps(Index: string): string;
17.     procedure WriteProps(Index: string; AValue: string);
18.   public
19.     constructor Create;
20.     destructor Destroy; override;
21.     property Props[Index: string]: string read ReadProps write WriteProps;
22.   end;
23.  
24. implementation
25.  
26.  
27. { TSomething }
28.  
29. function TSomething.ReadProps(Index: string): string;
30. begin
31.   Result := fMyValues.Values[Index];
32. end;
33.  
34. procedure TSomething.WriteProps(Index: string; AValue: string);
35. begin
36.   fMyValues.Values[Index] := aValue;
37. end;
38.  
39. constructor TSomething.Create;
40. begin
41.   fMyValues := TStringList.Create;
42. end;
43.  
44. destructor TSomething.Destroy;
45. begin
46.   fMyValues.Free;
47.   inherited Destroy;
48. end;
49.  
50. end.  
51.  

usage

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

1. program Project1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses
6.   {$IFDEF UNIX}{$IFDEF UseCThreads}
7.   cthreads,
8.   {$ENDIF}{$ENDIF}
9.   Classes, unit1
10.   { you can add units after this };
11.  
12. var
13.   t: TSomething;
14.  
15. begin
16.   t:= TSomething.Create;
17.   t.Props['hello'] := 'goodbye';
18.   writeln(t.Props['hello']);
19.   readln;
20. end.  

[molly]

Guys, Read the first topic again. It has nothing to do with the object properties of a component.

I admit i was a bit off-topic. but not by too much. No it is not about components but you can use (published) properties to (automatically) store your 'settings'.

Kembill has some values in his progrem to save it by user / desktop. These values has to be saved and loaded again. XML is nice.

Exactly. None of my suggestions where off-topic in that regards. TXML/IniPropStorage does just that.

Because I don't store settings in components  . I think it's stupid, rigid, inefficient, and a bad design  . I just use components when settings are editable.  But anyway it's just my opinion  I could be wrong.

Fair enough  Ill try to have a better look at your miConfig, especially before making specific comments.

[Edson]

Guys, Read the first topic again. It has nothing to do with the object properties of a component.
Kembill has some values in his progrem to save it by user / desktop. These values has to be saved and loaded again. XML is nice.

Yes. You're right but this is not so out of topic. It's just in the comments, I suggest to use: https://github.com/t-edson/MiConfig, like an option. But then someone (or "someones") ask me why to use that, and then I explain that MiConfig can, additionally, associate a variable to a COMPONENT, to facilitate the edition of that variable in a dialog.

Fair enough  Ill try to have a better look at your miConfig, especially before making specific comments.

Maybe I don't explain it well. "Words don't come easy to me" but I think this library can be useful, and at least it's very useful to me, when using this architecture:

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

1. Disk <---> Variables <---> Visual Component
2.                ^                  ^
3.                |                  |
4.                |           I only use this
5.        My program works    when need to edit
6.           with this         the variables
7.