Topic: Want to pass items around without casting....

[jmaeding]

I am noticing that if I use arraylists to pass items around, I can make functions that accept any type, and spit back any type.
I know people will say to just pass items as objects, but then I can't know the original class type exactly.
I can say, paraphrased, if (myObject is myClass) do such and such.
I can't test for the most specific type of the myObject though, because the IS function only tests if it inherits from that class.

If I wrap something in an arraylist, I can easily say typeof(myArraylist[0]), and get the exact type of the object.
Its like the arraylist does not have to box things, and spits them back unboxed.

Did I get that wrong?  I'm getting mixed signals with the tests I am doing.

[jmaeding]

man, guess I was a whole lot more interested in the topic than anyone else.
Here is a hopefully more relevent question:

For programs that have complicated dialogs, do you pass settings around by:
1) make a custom object per dialog to contain the settings, and pass it from the main program to the dialog, and back.
2) give the dialog private properties, and fill them in before showing from some variable global to the program, then re-gather properties at end before closing the dialog?
3) use a hashtable or some public variable that the dialog can use to fill itself in, and modify as needed.

All of these work, I am curious what balance others have found.
Custom objects for every dialog are a pain, but the properties idea is handy.
Any feedback appreciated.

[pkohut]

It depends - How much do you want to keep seperate the business logic
from the view logic.

Paul

man, guess I was a whole lot more interested in the topic than anyone else.
Here is a hopefully more relevent question:

For programs that have complicated dialogs, do you pass settings around by:
1) make a custom object per dialog to contain the settings, and pass it from the main program to the dialog, and back.
2) give the dialog private properties, and fill them in before showing from some variable global to the program, then re-gather properties at end before closing the dialog?
3) use a hashtable or some public variable that the dialog can use to fill itself in, and modify as needed.

All of these work, I am curious what balance others have found.
Custom objects for every dialog are a pain, but the properties idea is handy.
Any feedback appreciated.

[jmaeding]

Lets say I want completely separate.
You still have to decide if you make an object with whatever props to send to the dialog, or to send the dialog a hashlist of named variables.  You could send in an arraylist too, or other home rolled collection of stuff.

just trolling for ideas

[It's Alive!]

.
... or to send the dialog a hashlist of named variables...
just trolling for ideas

I sometimes use a dictionary<>

[pkohut]

Item 1 provides more flexability, but is more code to write. It's basically
your middle tier layer which allows for the separation of church and state
(business / display logic).  So say you create a structure to pass data
back and forth, then changes in the business code are less likely
to break the dialog code and vis-a-versa.  If need be you can also
copy the data structure to use while the dialog is being displayed.
If the user presses OK, then update the original data, otherwise throw it
away.

Item 2 works too, but breaks the design rules for OO style hiding of data.
Another option instead of item 2 is to use public getter/setters on the
private properties.

Either way they allow for data binding of variables to dialog control items.

In the end it's pretty much on a case by case need and the architecture of
your application for which way to go.

Paul

For programs that have complicated dialogs, do you pass settings around by:
1) make a custom object per dialog to contain the settings, and pass it from the main program to the dialog, and back.
2) give the dialog private properties, and fill them in before showing from some variable global to the program, then re-gather properties at end before closing the dialog?

[sinc]

I know people will say to just pass items as objects, but then I can't know the original class type exactly.
I can say, paraphrased, if (myObject is myClass) do such and such.
I can't test for the most specific type of the myObject though, because the IS function only tests if it inherits from that class.

You should be able to test exact classes.  For example, say we have two classes, Parent and Child.  Child derives from parent.  We then have:

Code: [Select]

Object item1= new Parent();
Object item2 = new Child();


if (item1.GetType() == typeof(Parent))
  ed.WriteMessage("\nItem 1 is a Parent!");
if (item2.GetType() == typeof(Parent))
  ed.WriteMessage("\nItem 2 is a Parent!");

if (item1.GetType() == typeof(Child))
  ed.WriteMessage("\nItem 1 is a Child!");
if (item2.GetType() == typeof(Child))
  ed.WriteMessage("\nItem 2 is a Child!");

The above code should return the results:

Code: [Select]

Item 1 is a Parent!
Item 2 is a Child!


If I wrap something in an arraylist, I can easily say typeof(myArraylist[0]), and get the exact type of the object.
Its like the arraylist does not have to box things, and spits them back unboxed.

That sounds funky...  The example I just gave might clarify it.  You would not typically use "typeof(myArraylist[0])"...  The argument to typeof() should be a Class.

You pretty much have it with the ArrayList.  But basically, what's happening is the data is being silently boxed behind the scenes.  Unfortunately, every time you perform some action on the ArrayList (such as sorting it), the data must be unboxed.  This leads to performance issues, and is why the ArrayList performs so much worse that the Generic Collections.  In general, the Generic Collections work so much better that the ArrayList has been sort of deprecated.

[sinc]

For programs that have complicated dialogs, do you pass settings around by:
1) make a custom object per dialog to contain the settings, and pass it from the main program to the dialog, and back.
2) give the dialog private properties, and fill them in before showing from some variable global to the program, then re-gather properties at end before closing the dialog?
3) use a hashtable or some public variable that the dialog can use to fill itself in, and modify as needed.

I usually use item 1.  It may seem like more code up-front, but it usually saves time and effort in the long run.

Item 2 is a bad idea, because global variables in general are a bad idea.  You could use static variables in a class.  But if you want to do something like this, you should do like Paul suggests, and add public getters/setters to your form.  Again, global variables are heavily frowned-upon, so you wouldn't want to populate to/from a global variable.  For more complex cases, where there are many possible variations of required and optional parameters, it may work best to add initialization methods to your form that set the variables.  This tends to make usage for your form clearer to other developers, and helps prevent improper initialization of the form.

Item 3 may be the best option for some usages, but that would be highly dependent on circumstances.  And again, it would involve something more like a singleton class or class with static methods, rather than a global variable.

[TonyT]

just trolling for ideas

Most .NET programmers that have made the
personal investment in learning to use the
.NET framework, would use Windows Forms
DataBinding, where controls on a dialog can
be 'connected' to a datasource (properties of
an object or columns of a table for example),
and once they are, the controls can directly
read/write the data from/to the datasource,
with no code required.

As far as finding out exactly how to go about
doing that (which would require far more time
and keystrokes than I and probably anyone else
here can expend), here's a good place to start:

  http://msdn.microsoft.com/en-us/beginner/default.aspx

[sinc]

That sounds like the best route.

That's basically the way we work in WebObjects (in the Apple world).  I kind of thought something like that was possible with DataSources, but it's far more obtuse and difficult to figure out in Visual Studio and .NET than it is in WebObjects (where it's so simple and obvious it's brain-dead).  I couldn't find any clear explanations of it when I was looking, though, and haven't taken the time to mess with it enough to figure it out yet.  Maybe it might be worth stopping and taking the time, though.

Now all it needs it the ability to use the mouse to graphically connect our business objects to our visual design elements, without typing anything, like WebObjects has been able to do ever since it was NeXTSTEP in the early 1990's...   

[jmaeding]

Thanks for the hint, Tony.
While I work with databases a lot, and am aware of binding them to controls, I did not have object binding on my radar.
I'm sure it was right in front of me too, as I have read a lot about it.
I will, indeed, go back and read that again.

Clever dig with the link, I'm glad the site said "No experience or programming knowledge required - so dive right in!"
You see, while you have the programming experience, I have the engineering knowledge to know what programs to write and how the users will react to them.  So its a mix.

[jmaeding]

I thought about this some more.
It makes sense to use dialog box specific settings objects for items that would be re-used a lot.
For dialogs that are specific to a program, I'm thinking its ok to just pass them a copy of the settings object you are using for the program. The settings object could be as raw as a hashtable or as nice as a custom class...
The dialog will be coupled to the format of the main programs settings, but that is ok because the two are closely tied anyway.  The key is you pass a copy of the global settings object, so you can record changes but cancel out and discard them too.

This is the kind of foundational stuff that you need to decide on up front, yet I bet in a year I will want to do it all differently as my code library and Napoleon-like bowhunting skills improve.  Almost like parenting

[TonyT]

Now all it needs it the ability to use the mouse to graphically connect our business objects to our visual design elements, without typing anything, like WebObjects has been able to do ever since it was NeXTSTEP in the early 1990's...   

Ummmm... It already does that.

Download this sample and follow the instructions and
you'll see how it works:

      http://www.caddzone.com/DataBindingSample.zip

[jmaeding]

one small step for Tony, one giant leap for Jameskind....

I was actually doing this exact thing with the Virtual Tree control made by infralution, but had not noticed that VS lets you do the same thing with native controls.  The examples always show binding to databases so just using an object slipped by.  Its obvious now, thx for the example.

[jmaeding]

I was curious to see what other downloads were on Tony's site, so stopped by.
We have used the free AcadXTabs here, and took a peak to see if it had any new features.
Of course, it did, and the new stuff is a lot more useful than the tabs feature itself IMO.
Its worth looking at as the tools are very unique and priced within reach.
Just looking at the features he did gave me ideas on program I am doing so its worth the effort to look through them.

[jmaeding]

Having looked at that example, its important to understand that the OnPropertyChanged detail is telling the bindingobject to update all controls hooked to the object, not just controls "involving" the scalefactor.
The fact is, we never told it some controls are dependent and some are not so it has to be that way.

Not a single one of my 5 VB.net or C# books mention using objects, only databases for this.  Its just one of those things that was so close, it would have bit me if it was a snake.

[pkohut]

Having looked at that example, its important to understand that the OnPropertyChanged detail is telling the bindingobject to update all controls hooked to the object, not just controls "involving" the scalefactor.
The fact is, we never told it some controls are dependent and some are not so it has to be that way.

Not a single one of my 5 VB.net or C# books mention using objects, only databases for this.  Its just one of those things that was so close, it would have bit me if it was a snake.

Set CausesValidation to false for the controls you don't want to participate in validation post backs.  See the
MSDN docs for "User input validation in Windows forms" and "Control.Validating Event".

Also, you may be interested in looking at the Property Grid control.  Through reflection, a bound object's
public properties are automatically shown in the grid.  Then through the use of attributes you can
control how the grid looks and feels.  Again, MS has a pretty good write up called
"Getting the Most Out of the .NET Framework PropertyGrid Control".

Paul

[jmaeding]

Good tips, thx

[TonyT]

Set CausesValidation to false for the controls you don't want to participate in validation post backs.  See the
MSDN docs for "User input validation in Windows forms" and "Control.Validating Event".

Also, you may be interested in looking at the Property Grid control.  Through reflection, a bound object's
public properties are automatically shown in the grid.  Then through the use of attributes you can
control how the grid looks and feels.  Again, MS has a pretty good write up called
"Getting the Most Out of the .NET Framework PropertyGrid Control".

Paul

The example uses an updown control, which is a
bit of a special case.

There is no control validation when you click the
up/down button regardless of what CausesValidation
is set to, yet the bound property's value is changed.

That's the reason why the datasource update mode
is set to OnPropertyChanged.