|
|
Home » Community » Coffee corner » Interesting....
|
Re: Interesting.... [message #1830 is a reply to message #1829] |
Tue, 21 March 2006 22:09 |
|
mirek
Messages: 14112 Registered: November 2005
|
Ultimate Member |
|
|
#include <CtrlLib/CtrlLib.h>
struct XmlDlg : public TopWindow {
Array<Label> label;
ArrayMap<String, EditString> edit;
ArrayMap<String, Option> option;
bool Load(const char *xml);
};
bool XmlDlg::Load(const char *xml)
{
int y = 10;
try {
XmlParser p(xml);
while(!p.IsTag())
p.Skip();
p.PassTag("dialog");
int linecy = Draw::GetStdFontCy() + 4;
while(!p.End())
if(p.TagE("option")) {
Add(option.Add(p["id"]).SetLabel(p["label"]).TopPos(y, linecy).LeftPos(10, 100));
y += linecy + 4;
}
else
if(p.TagE("edit")) {
Add(label.Add().SetLabel(p["label"]).TopPos(y, linecy).LeftPos(10, 30));
Add(edit.Add(p["id"]).TopPos(y, linecy).LeftPos(40, 60));
y += linecy + 4;
}
else
p.Skip();
}
catch(XmlError e) {
Exclamation("XML error: " + e);
return false;
}
SetRect(0, 0, 110, y + 10);
return true;
}
GUI_APP_MAIN
{
XmlDlg dlg;
if(!dlg.Load(LoadFile(GetDataFile("dialog.xml"))))
return;
dlg.Run();
int q = dlg.edit.Find("E1");
if(q >= 0)
PromptOK("E1 value: " + DeQtf(AsString(~dlg.edit[q])));
}
<?xml version="1.0"?>
<dialog>
<option id="O1" label="Option"/>
<option id="O2" label="Another option"/>
<edit id="E1" label="Text"/>
<edit id="E2" label="Text2"/>
</dialog>
[Updated on: Tue, 21 March 2006 22:37] Report message to a moderator
|
|
|
Re: Interesting.... [message #1834 is a reply to message #1830] |
Wed, 22 March 2006 08:45 |
|
Very good example Mirek!
Personaly I don't like xml (html, and any kind of unreadable text format.. , but most of people should like it because it follows the market trends.. (xml everywhere..)
|
|
|
|
Re: Interesting.... [message #1838 is a reply to message #1835] |
Wed, 22 March 2006 13:36 |
hojtsy
Messages: 241 Registered: January 2006 Location: Budapest, Hungary
|
Experienced Member |
|
|
I am afraid this will not satisfy the critics. It is still just an example supporting only two control types, and very limited set of properties. And you are unable to place the controls to horizontal or vertical groups of controls. The window width, and control sizes are hardcoded. It shows that dinamic generation can be done from client code, but only if the client goes and implements all of it - it's not a feature ready to be used. (Situtation is simmilar with HtmlBrowser control)
[Updated on: Wed, 22 March 2006 13:37] Report message to a moderator
|
|
|
|
|
Re: Interesting.... [message #2419 is a reply to message #2418] |
Wed, 12 April 2006 13:20 |
|
mirek
Messages: 14112 Registered: November 2005
|
Ultimate Member |
|
|
Ah,
well, it is a little bit hard to explain, but....
U++ layouts are designed in a way that leads to "dialogs as structs". Means each layout naturally generates some C++ struct that contains widgets as members. This is one of dominant reasons why coding in U++ is so fast.
Now with dialogs stored in XML, this feature would be lost, because you would have to dynamically create dialogs by parsing XML and best you could hope for is to access widgets using some sort of textual IDs. U++ productivity gone.
While it is quite possible to implement this in U++, the question is why? If some real world app needs this, it will have most likely other very specific requirement, satisfying them would be most likely harder than "XML dialog" skeleton code, which really is quite primitive.
Just a side note - I have couple of applications that store sort of dialog layouts in Oracle. Then others that store dialog layouts in proprietary text format. Still I do not see any advantage to provide some fixed facilities for dynamic dialogs.
Mirek
|
|
|
Re: Interesting.... [message #23521 is a reply to message #2419] |
Tue, 27 October 2009 09:44 |
|
luzr wrote on Wed, 12 April 2006 14:20 | Ah,
well, it is a little bit hard to explain, but....
U++ layouts are designed in a way that leads to "dialogs as structs". Means each layout naturally generates some C++ struct that contains widgets as members. This is one of dominant reasons why coding in U++ is so fast.
Now with dialogs stored in XML, this feature would be lost, because you would have to dynamically create dialogs by parsing XML and best you could hope for is to access widgets using some sort of textual IDs. U++ productivity gone.
While it is quite possible to implement this in U++, the question is why? If some real world app needs this, it will have most likely other very specific requirement, satisfying them would be most likely harder than "XML dialog" skeleton code, which really is quite primitive.
Just a side note - I have couple of applications that store sort of dialog layouts in Oracle. Then others that store dialog layouts in proprietary text format. Still I do not see any advantage to provide some fixed facilities for dynamic dialogs.
Mirek
|
An interesting discussion i missed here.
About dynamic dialogs...
The main reason of dynamic dialogs is possibility to separate programming work by design work. With dynamic dialogs will be possibility to integrate styles too (visual styles)!
I think that is more important to make work easy even if is detrimental for running speed.
With this possibility will be possible to integrate forms in web browser! It is Not bad idea!
Ion Lupascu (Tojocky)
|
|
|
Re: Interesting.... [message #23523 is a reply to message #23521] |
Tue, 27 October 2009 10:59 |
andrei_natanael
Messages: 262 Registered: January 2009
|
Experienced Member |
|
|
tojocky wrote on Tue, 27 October 2009 10:44 |
luzr wrote on Wed, 12 April 2006 14:20 | Ah,
well, it is a little bit hard to explain, but....
U++ layouts are designed in a way that leads to "dialogs as structs". Means each layout naturally generates some C++ struct that contains widgets as members. This is one of dominant reasons why coding in U++ is so fast.
Now with dialogs stored in XML, this feature would be lost, because you would have to dynamically create dialogs by parsing XML and best you could hope for is to access widgets using some sort of textual IDs. U++ productivity gone.
While it is quite possible to implement this in U++, the question is why? If some real world app needs this, it will have most likely other very specific requirement, satisfying them would be most likely harder than "XML dialog" skeleton code, which really is quite primitive.
Just a side note - I have couple of applications that store sort of dialog layouts in Oracle. Then others that store dialog layouts in proprietary text format. Still I do not see any advantage to provide some fixed facilities for dynamic dialogs.
Mirek
|
An interesting discussion i missed here.
About dynamic dialogs...
The main reason of dynamic dialogs is possibility to separate programming work by design work. With dynamic dialogs will be possibility to integrate styles too (visual styles)!
I think that is more important to make work easy even if is detrimental for running speed.
With this possibility will be possible to integrate forms in web browser! It is Not bad idea!
Ion Lupascu (Tojocky)
|
I don't see how you separate the code from the app design. You write handlers for widgets events. Even if you create a descriptive form of a window in XML file you still should parse that file, create widgets based on what you get from that file and your application should do something when user push a button or something. So the design of application imply also code.
How you will integrate styles? You cannot write CSS style attached to XML because U++ does know nothing about it.
I see the only benefit of a XML based design only when you write plug-ins which know nothing about your GUI. You write a XML file with description of (allowed) widgets in it(containing widget name, position, etc) and then write event handlers(callbacks). Your app analyze the XML file, create a proper window based on info found in it and when an event occur from that window widgets it call your callbacks in plug-in, and your plug-in is doing his work. So, your plug-in may use the GUI without knowing nothing about it (you may use U++, Qt, GTK+, etc) and you don't have to change code in widget if for example you changed a widget name in your GUI library.
|
|
|
Re: Interesting.... [message #23531 is a reply to message #23523] |
Wed, 28 October 2009 13:34 |
mdelfede
Messages: 1308 Registered: September 2007
|
Ultimate Contributor |
|
|
I also don't see much point on having dialogs/controls in XML, or, weel, just a possible point, the dialog testing phase, on which you can "look" at dialogs without using them.
May be somehow useful, indeed, but it's also easy to write few upp code lines and show the same dialog using upp.
Another possible use would be to make dialogs with another app (which ???) and then export them to upp.... but then you'll have to connect dialogs to code anyways.
I'd see more useful some tool to convert dialogs from other toolkits to Upp. That would spare some porting time.
Ciao
Max
|
|
|
Goto Forum:
Current Time: Sun Nov 10 20:40:30 CET 2024
Total time taken to generate the page: 0.02601 seconds
|
|
|