0

I already know how to use inline templates (prop/propf + CTRL-J) to declare properties that automatically create their private field and their getters/setters, but how do I do the opposite?

I have 166 private fields already declared. Is there a way to have the Delphi IDE automatically create properties for each one of them?

This is what I have:

TMyObject = class(TPersistent)
private
  FFirstProp: boolean;
  FSecondProp: boolean;
  // 164 more of them...

This is what I would like to (ideally) have the IDE create for me:

published
  property FirstProp: boolean read FFirstProp write FFirstProp;
  property SecondProp: boolean read FSecondProp write FSecondProp;
  // and the other 164...
FjodrSo
  • 301
  • 2
  • 8
  • I'm pretty sure this is not an option. Your best bet is to do it the other way around. Convert all these to property definitions and then produce the private fields. Because how is the IDE supposed to know if you want either getters or setters? Or if you want to link them directly or indirectly? Or what the defaults should be? – Jerry Dodge Apr 15 '15 at 16:55
  • Or which of those private fields you want to be properties and which you do not? Or whether you want them to be public or published? – Ken White Apr 15 '15 at 16:56
  • Can use propf again, type FirstProp and no additional field will be declared. – Sertac Akyuz Apr 15 '15 at 16:57
  • Jerry, a simple code generator that "assumes" direct read/write of the private field would be enough for me. After all, even the other way around the IDE must make assumptions... – FjodrSo Apr 15 '15 at 16:58
  • Thank you Sertac, I know that... I was trying to avoid so much typing... – FjodrSo Apr 15 '15 at 16:59
  • Personally I don't know such feature in the Delphi IDE. But you always can to use the third-party text editor with macros support. Notepad++ is the good example. – Abelisto Apr 15 '15 at 17:06
  • You could use an external script to generate this. Would be simple enough in, say, Python. – David Heffernan Apr 15 '15 at 17:11
  • David, thank you, I am actually doing it with a tiny script. Also, this question is not a duplicate. I actually saw the other answer and even quoted part of it in my question (Ctrl-J) so no duplicate here, thank you. – FjodrSo Apr 15 '15 at 18:33
  • you could create an app that hat pares the code and generates you what you want , that way you could have it do the getters and setters for you if required, for example and have tags after the declaration that tell your app what to do, it could also write the stuff getter and setter functions/procedures TMyObject = class(TPersistent) private FFirstProp: boolean; //Get,Set FSecondProp: boolean; //Set – Shaun07776 Apr 15 '15 at 20:28
  • Looks like a dupe to me. Both questions ask how to auto create props efficiently. – David Heffernan Apr 15 '15 at 21:08
  • 1
    I had read that question and answer before asking mine. If that was the answer I was looking for, do you think I would ask this question? This is the other way around PrivateSymbol -> Property, not Property -> PrivateSymbol. "How to auto create props efficiently" is too simplistic. Then why don't we flag as duplicate all questions about properties cause they're all "about properties"? Sorry, it's really not the same... – FjodrSo Apr 15 '15 at 21:32
  • 1
    *If that was the answer I was looking for, do you think I would ask this question?* It's not about answers. It's about questions. And sure it's the other way around in your head. But all you really want to do is make properties effectively. Which is what the other question asks. Doesn't actually matter which way round. – David Heffernan Apr 15 '15 at 21:57
  • @David "Would be simple enough in, say, Python. " Or you could just take a page from Python's playbook and simply make everything public and program for consenting adults. :-) Seriously it's just madness to declare everything twice like that without needing real getters and setters. If you have to consider using another language to generate code for your language, that's got to be a sign you're doing something wrong. – alcalde Apr 16 '15 at 07:32
  • 1
    @alcalde I agree that if the class really contains 164 properties of that form, then they should just be published data members. – David Heffernan Apr 16 '15 at 12:13
  • @David: the way around matters, and the proof is that - in fact - there is a way to do it one way (prop + Ctrl-J), and there's no way to do it the other way around. – FjodrSo Apr 16 '15 at 22:41
  • 1
    So if I reopen the question and somebody answers, "What you ask for cannot be done", then you'll upvote and accept? – David Heffernan Apr 16 '15 at 22:44
  • Yes, cause that someone would have answered my question and deserves the acceptance and the upvote. – FjodrSo Apr 17 '15 at 22:53

0 Answers0