Manuel,
Many thanks for your excellent contributions, as usual
Your application is with no doubt a very usefull tool and its source code surely is a great help for mastering FiveWin programming.
Regarding the designer itself, I see it uses the same model that Visual Objects used ("one way tool") which has a major problem: if the user wants to modify the form after the PRG has been modified with extra source code, this extra source code gets lost. Thats was the main complain about Visual Objects designer.
The benefit of using a resources file is, as you know, that if you decide to modify the dialogbox, you can do it, and it won't affect your existing PRG source code, asuming that a good programming style has been used in the PRG
Even the "two way tools" implemented by Borland, have the problem that I describe above. They are not "clever" enough to detect what components names you have changed and where you are using them in your code, and how you are using them.
So meanwhile the computers don´t get smarter than programmers, we have to keep coding "by hand" as usual
Its just my personal opinion, and we are open to listen all other opinions.
Visual FiveWin from Manuel Mercado
- Antonio Linares
- Site Admin
- Posts: 37481
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Contact:
Hi Antonio:Antonio Linares wrote:Regarding the designer itself, I see it uses the same model that Visual Objects used ("one way tool") which has a major problem: if the user wants to modify the form after the PRG has been modified with extra source code, this extra source code gets lost. Thats was the main complain about Visual Objects designer
As i said at spanish forum, the final conceptualization of Visual Fivewin is 100% 2 way considering all of the project's components, including forms design and supplementary code.
Many thanks for your comments.
Best regards.
Manuel Mercado
- Antonio Linares
- Site Admin
- Posts: 37481
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Contact:
IMO we should first agree on the formats to use:
In order to save forms to files ("serialization") and later restore them, I would propose to use XML as it will provide us the greatest freedom to extend our "serialization" model as much as needed.
i.e. Mac OSX NIB files use XML (they are named .pList files: "properties list")
In order to save forms to files ("serialization") and later restore them, I would propose to use XML as it will provide us the greatest freedom to extend our "serialization" model as much as needed.
i.e. Mac OSX NIB files use XML (they are named .pList files: "properties list")
-
- Posts: 824
- Joined: Thu Oct 13, 2005 7:39 am
- Location: Germany
-
- Posts: 824
- Joined: Thu Oct 13, 2005 7:39 am
- Location: Germany