PLS HELP - User-Designing form in run-time

[MuZZy]

HI,

We have a pretty large application with hundreds of forms in it. Now some of our new clients request
us to make some custom screens(forms), which basicly comes to rearranging controls on our standard
forms - moving existing text boxes, grids, etc. around. We currently are creating custom versions of
forms for them and put some sort of flag in their database, so that application knows which version
of a form to load depending on client.

But obviousely it can't go this way any longer as we are unable to support multiple screens of same
nature, so we want to add certain functionality to be able to rearrange components on a form on
run-time, without rebuilding the app. Something like: user clicks a button "Redesign form" and then
he/she is able to move controls around on a form. Then they click "Save" and current positions and
size of controls is saved somewhere in teh database, so that the next time the form is pulled up, it
rearranges the controls per values in database.

SO my problem here is how to provide the app with form editing ability.

Any ideas/coments would be HIGHLY!!! appreciated...

Thank you,
Andrey

[PMGuy]

Andrey:

Without going into a great deal of detail, any object can be configured
to respond to drag-drop events. So, at the click of a button, you
could make all objects read-only and force them to only respond to drag
drop events, changing the top & left properties based on where the
object gets dropped.

The functionality could be as sophisticated as you're willing to make
it. Bear in mind that you'd need some kind of engine to logically
re-assign the tab order.

Personally, I think it would be easier for you to move things around
according to a specification. The solution proposed above could be
subject to a great deal of un-expected behavior and your company could
spend a great deal of time creating this "customizat ion" piece and, if
your client is as they seem to be, the client is likely to be
dissatisfied with your solution.

I think a better solution would be to design a routine where you could
analyze a form prior to a build and record the arrangement of the
objects in a client specific file. That way, you'd really only need to
maintain a single form and then, just prior to building the build for a
particular client, you could run your script to read the object
configurations and then move everything around automatically.

Does that solution sound to esoteric? If you think that might be
do-able, I'd be happy to brainstorm with you a bit.

[Bruce Wood]

I agree. Some sort of scheme whereby you create an XML config file
holding attributes based on the name of the control. Then all you need
is a base class that reads the config file in the form's OnLoad method
and moves / sizes / hides / shows controls based on what's in the XML
file.

Throw in some inherited controls that have an editing mode that allows
them to be repositioned, resized, etc at run time, and ways for the
user to change other properties (visibility, tab order, perhaps a
default value if invisible, etc).

Then a save operation that your base class form recognizes as a signal
to regenerate the XML config file.

Sounds like fun. :-)

[MuZZy]

PMGuy wrote:

Andrey:

Without going into a great deal of detail, any object can be configured
to respond to drag-drop events. So, at the click of a button, you
could make all objects read-only and force them to only respond to drag
drop events, changing the top & left properties based on where the
object gets dropped.

The functionality could be as sophisticated as you're willing to make
it. Bear in mind that you'd need some kind of engine to logically
re-assign the tab order.

Personally, I think it would be easier for you to move things around
according to a specification. The solution proposed above could be
subject to a great deal of un-expected behavior and your company could
spend a great deal of time creating this "customizat ion" piece and, if
your client is as they seem to be, the client is likely to be
dissatisfied with your solution.

I think a better solution would be to design a routine where you could
analyze a form prior to a build and record the arrangement of the
objects in a client specific file. That way, you'd really only need to
maintain a single form and then, just prior to building the build for a
particular client, you could run your script to read the object
configurations and then move everything around automatically.

Does that solution sound to esoteric? If you think that might be
do-able, I'd be happy to brainstorm with you a bit.

Thankyou for your responces, guys! Well, that was the idea "behind the scene" - to have only one
"template" form and keep customization parameters like location and size of controls in a
client-specific table. The problem is that we need to somehow create such table/xml schema - so the
easiest way would be to design such a schema using a run-time designer, which could be used by
non-programmers in our company - obviousely we wouldn't give such a tool to clients.

So i still in problem of getting a designer to rearrange the form and then "flush" the custom
parameters to a table/xml.

Any ideas?

Thank you,
Andrey

[PMGuy]

Since functionality/behavior would need to be the same, I would assume
that the only information that you'd need to save for each object would
be the following:
..top
..left
..width
..height
..{font} - there are a handful of font properties
..TabOrder

[MuZZy]

PMGuy wrote:

Since functionality/behavior would need to be the same, I would assume
that the only information that you'd need to save for each object would
be the following:
.top
.left
.width
.height
.{font} - there are a handful of font properties
.TabOrder

Right, but to get those i need to have some sort of an IDE, otherwize it's a tricky task to manually
get those parameters if i have couple hundreds of controls on my form. So again, i would need some
kind of visual tool to arrange those.

Any ideas in this directions?

Thank you
Andrey

[PMGuy]

Andrey:

I'm not sure what exactly you're asking and I don't understand why it's
tricky.

If you build a recursive function (GetGUIProps()) which starts at the
form and drills into each object/container and simply write these
properties out to an XML file, then you can create another function
(SetGUIProps()) which does the same, only in reverse (read the XML and
set the property value). This is the one that gets run just prior to
displaying the form (call it from InitializeCompo nent()? perhaps)

Your visual tool is Visual Studio. I'm assuming that you're using
version control, so simply check out the form and make your edits. You
could hard-code your app so that GetGUIProps() can only be run in debug
mode. So you can move everything around according to client specs and
then run GetGUIProps() to create/update your XML file when you run the
app from VS.

I suppose for future support, you'll need to write an alternate version
of SetGUIProps() which does a search and replace on the .cs file.

Does that make sense?

[Bruce Wood]

I believe that the idea here is to give the _users_ the ability to do
this, without buying each of them a Visual Studio license, which would
not only be pricey but a security nightmare.

MuZZy... I'm sure that there are ways to give controls "handles" at run
time so that they can be sized and dragged, and a little cleverness
would allow users to hide controls, set default values for them, etc.
Yes, in effect, you have to build a simple IDE, but I think that there
are ways to make controls manipulable at run-time, which is the hardest
part.

Perhaps the people over in microsoft.publi c.dotnet.window sforms or
....windowsform s.controls would be able to help you there.