GUI Design Question

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello all

We are creating a generic front end for a CF application that needs to be used for several different customers and have a dilemma about how to impliment it. As far as I can see there are two options
1. We could use standard CF forms, using inheritance and creating components to reuse common groups of controls, O
2. We could use forms that are "Serialized" at design time to XML (i.e write the forms in XML) and then create the controls dynamically at runtime from the XML

It seems that using form inheritance is the most common method although my limitied experience shows that workarounds for visual inheritance are clunky and you end up ignoring the deigner and writing forms by adding controls manually

Using the second option, it would be possible to create a simple IDE that generates XML for the form

Any thoughts on which is the "best", most scalable method

Thanks in advanc

Simon Nev
 
I think I don't really understand your concerns.
However I could tell you that a Form, created and compiled, with plenty of
control, might takes already a few seconds to instantiate.
Moreover reading/writting a XML document is slow (I had XML document, I drop
them in favor of binary document and increase my reading/writting data file
3 fold)
So I would advice you to design your form ....
But, again, I'm not really sure I understand you ...

Simon Neve said:
Hello all,

We are creating a generic front end for a CF application that needs to be
Click to expand...
used for several different customers and have a dilemma about how to
impliment it. As far as I can see there are two options:
1. We could use standard CF forms, using inheritance and creating
Click to expand...
components to reuse common groups of controls, OR
2. We could use forms that are "Serialized" at design time to XML (i.e
Click to expand...
write the forms in XML) and then create the controls dynamically at runtime
from the XML.
It seems that using form inheritance is the most common method although my
Click to expand...
limitied experience shows that workarounds for visual inheritance are clunky
and you end up ignoring the deigner and writing forms by adding controls
manually.
 
In fact, we had done the second option as a product in Traditional-Chinese.
However, it takes longer time to implement.

I would like to know your concerns, for example, do you wish to handle
source code when you develop different projects.
In the first option, you have to hadle all the source code every time.
And in the second, you can develop an IDE to handle GUI by drag-n-drop
without writting any more code, but that might lose some flexibility.

--
Best Regards,
Jan Yeh

MVP(Windows CE.NET), MCAD, .NETcf Developer & Consultant
Mobile Mind Co., Ltd. @ Taiwan
 
Sorry I should have been more clear..
Our application is a kiosk type application with big buttons so that users with gloves on can use the system, this means that many of our forms have only 6 buttons and in our last project we ended up with 200+ forms. There are 6 types of form and would be perfect for visual inheritance. However, the workarounds for visual inheritance that I have seen mean that the developer can't see the base controls in the derived forms designer and the developer in reality finds it easier to add/ change controls by writing code in the derived form. This is OK for a few forms but I worry this is slow process with many forms

By passing an XML string into the constructor of the form, the form can create and position it's own controls at runtime. By using XML it would be possible to create simple IDE which would allow the developer to create the buttons and then generate the XML which could be interpreted at run time. This also has other advantages such as being able to download the next form via a web service..

Am i right in thinking that using the Designer to create derived forms is a painful process
 
Back
Top