How to pass a reference itself

[Rich S.]

I want to pass an object to a dialog box, and have the dialog box work on the
object, so that when the dialog box closes, my program now sees the altered
object.

This turns out to be not as simple as passing a pointer in a native program.

How can I pass the object into the dialog box constructor, so that all of
the functions in the dialog box class will act upon the original object?

I tried passing the object with the "ref" parameter, but this seems to have
effect only within the immediate function being called. It doesn't have
effect over the whole dialog box class (of course.)

Thank you,
Rich

[Marc Gravell]

Assuming your dialog box isn't itself creating a new/different instance,
this /should/ work just fine; the real question is: what is your dialog
doing (perhaps wrongly). The way to do this is something like:

public class MyDialog : Form {
private readonly MyDataClass instance;
public MyDialog() {} // need default ctor for designer - plus all the
initialise component jazz
public MyDialog(MyDataClass instance) : MyDialog() { // no need for ref
unless the ctor reassignes the parameter
this.instance = instance;
}
}
(you could also use a property getter/setter around "instance" instead of
the ctor)

Now - the important thing is what your dialog does; what it /should/ do
(assuming we want immediate updates) is update the underlying instance:

private void SomeButton_Click(object sender, EventArgs e) { // typically
an apply button
instance.SomeProperty = true; // or some such manipulation; typically
reading values from contained controls
}

Having done this, we have updated the underlying object. So does this
approach not work for you? Note that if you are using data-binding, then
your object must support either the INotifyPropertyChanged interface (in
2.0), else the {PropertyName}Changed pattern (1.1) for the original UI to be
notified of the updates.

Does this help any?

Marc

[Marc Gravell]

second ctor should read ": this()", not ": MyDialog()"; the perils of
notepad coding...

Marc

[Marc Gravell]

And a final thought; things will work *very* differently if you have a
struct instead of a class; class would be normal for this usage.

If you are using a struct (for whatever reason), then the property getter /
setter is the way to go - i.e. you set it before showing the UI (creating a
clone in the process), update it (the clone) in the UI, and then (after
closing) read the value from the getter (creating a *3rd* instance),
assigning that back to your original variable. Like I say : class would be
normal usage here!

Marc

[Rich S.]

Hi Marc,

Thank you for your very thoughtful reply. I can't explain exactly why I was
having trouble, but for some reason, when the dialog box returned from
ShowDialog, the original instance was not updated to reflect changes from the
dialog box.

I solved the problem by putting a method into the dialog class that simply
returns the object instance inside the box, so that before the box is
disposed, I am retrieving it.

But the next time I implement a dialog box, I will definitely do it the way
you describe.

Thanks again,
Rich

"Marc Gravell" wrote:

And a final thought; things will work *very* differently if you have a
struct instead of a class; class would be normal for this usage.

If you are using a struct (for whatever reason), then the property getter /
setter is the way to go - i.e. you set it before showing the UI (creating a
clone in the process), update it (the clone) in the UI, and then (after
closing) read the value from the getter (creating a *3rd* instance),
assigning that back to your original variable. Like I say : class would be
normal usage here!

Marc

[vj]

This is true... the Object will be lost, even tho it is by ref... as the
dialog box will disposed. You have to take it out, before you dispose the
dialog box..,
VJ

"Rich S." <Ri***@discussions.microsoft.com> wrote in message
news:F0**********************************@microsof t.com...

Hi Marc,

Thank you for your very thoughtful reply. I can't explain exactly why I
was
having trouble, but for some reason, when the dialog box returned from
ShowDialog, the original instance was not updated to reflect changes from
the
dialog box.

I solved the problem by putting a method into the dialog class that simply
returns the object instance inside the box, so that before the box is
disposed, I am retrieving it.

But the next time I implement a dialog box, I will definitely do it the
way
you describe.

Thanks again,
Rich

"Marc Gravell" wrote:

And a final thought; things will work *very* differently if you have a
struct instead of a class; class would be normal for this usage.

If you are using a struct (for whatever reason), then the property getter
/
setter is the way to go - i.e. you set it before showing the UI (creating
a
clone in the process), update it (the clone) in the UI, and then (after
closing) read the value from the getter (creating a *3rd* instance),
assigning that back to your original variable. Like I say : class would
be
normal usage here!

Marc