C# equivilant

[sjn78]

In VB I had this

 

Sub OpenForm(ByRef myForm as Form)

 

Dim f As New Form()

f = myForm

 

f.show()

 

End Sub

 

 

Some other event would contain this

 

OpenForm(New frmAddress())

 

How do I achieve this in C#

 

Thanks

[Jaco]

In VB I had this

 

Sub OpenForm(ByRef myForm as Form)

 

Dim f As New Form()

f = myForm

 

f.show()

 

End Sub

 

 

Some other event would contain this

 

OpenForm(New frmAddress())

 

How do I achieve this in C#

 

Thanks

 

After removing the erroneous "ByRef", and running it through the Instant C# vb to C# converter, I get:

 

public void OpenForm(Form myForm)

{

Form f = new Form(); //no need to set it to a new "Form", by the way...

f = myForm;

 

f.Show();

}

 

OpenForm(new frmAddress());

 

But if your code was as simple as the example, you could also do:

public void OpenForm(Form myForm)

{

myForm.Show();

}

[Joe Mamma]

Sub OpenForm(ByRef myForm as Form)
Dim f As New Form()
f = myForm
f.show()
End Sub

' . . . snip . . . 

OpenForm(New frmAddress())

 

Do you actually want to create two Forms???

 

I wouldnt do anything like you have done here as it is not Object Oriented.

I want frmAddress to know what to do with itself (oriented towards the object - OOP) and not relegate operations on frmAddress to another procedure (Procedureal Programming)

 

This is precisely what I mean about the VB construct encouraging non-OOP design

 

I would do define AddressForm [accepted Nomenclature for OO design, call it what it is!]

 

public class AddressForm: Form
{
public static Form ShowForm()
{
	Form _frm = new AddressForm();
	_frm.Show();
	return _frm;
}
}

 

and in your event:

 

Form aFrm = AddressForm.ShowForm();

 

this might seem extremely foreign, but it is a typical OO implementation.

 

the equivalent in VB:

Public Class AddressForm
	Inherits Form
Public Shared Function ShowForm() As System.Windows.Forms.Form
	Dim _frm As Form = New AddressForm
	_frm.Show()
	Return _frm
End Function
End Class

 

and in your event:

 

Dim aFrm as Form = AddressForm.ShowForm();

Edited July 10, 2004 by Joe Mamma

[Denaes]

I wouldnt do anything like you have done here as it is not Object Oriented.

 

I understand many of the basic mechanics of OOP. The how to... Do you have any advice or know of any books dealing more with the theory and common practices?

 

More of WHY you do it a certain way, HOW you come up with OOP designs, but less of the mechanics on how to impliment it.

 

Most of what I've been doing recently has been quasi OOP after a fashion... seems to be more Component Oriented.

 

If I use a group of controls more than once, or the controls share a common function (like the navigation controls for a database; next, prev, first, last, etc) I seem to be making Controls out of them.

 

I make a single control out of all of the textboxes on a form that deals with Database issues, that way it's easier to Black Box the processes of databinding, rendering all the controls inert (view only), allowing input (edit), clearing & allowing input (new record) and sometimes swapping out text for combo boxes (where selections can be made).

 

I'm sure it's not nearly proper OOP, but I try to do a base class that contains much of the functionality - then inheriting it with more specific controls.

[ThePentiumGuy]

sjn78: i beleive (im really not sure) that 'ByRef' is equivalent to 'in' in C#.. for example

 

int increment(in number)

{

number++;

}

 

and when you call it you'd say

increment(out mynumber);

 

dont quote me on this :p, actually this is one of the advantages(please, no flame war ;)) that C# has over vb.net: you can clearly see what arguments are byVal and byRef when you're calling a function

 

pent

[Joe Mamma]

sjn78: i beleive (im really not sure) that 'ByRef' is equivalent to 'in' in C#.. for example

 

int increment(in number)

{

number++;

}

 

[/QOUTE]

 

actually it is 'ref' on both side, the def and the call.

there is the 'out' key word too. ref parameters must be initialized before passing, out parameters dont need to be.

[sjn78]

When I was learning C and C++ in Uni, we used pointers to directly access an object or variable. Are they still used in that sense? Or is it different such as you use ref or pass the value to the sub?

[PlausiblyDamp]

Pointers are still supported in .Net but only as a means of interop with other non-managed languages.

Within .Net variables that are classes are passed by reference (equivalent of a type safe pointer), structs are a value type and passed as a copy of the data. As a consequence there is no real need to use pointers (and the associated pointer arithmetic) in most .Net based programs.

ref (or ByRef in VB) allows you to pass a reference to a variable which behaves like a pointer in most scenarios (but without the associated lack of type safety) - however I would also suggest either searching these forums or MSDN for a bit more detail as it isn't quite as obvious as it first seems.

[ultraman]

I often use the keyword "ref" in C# that works just like ByRef in VB. But you have to use it when you pass the param too.

 

Ex :

 

public void WriteText(ref TextBox txtTest)
{
txtTest.Text = ""This is a test"
}

WriteText(ref txtMyMessage);

 

 

I know this won't solve your problem, but that's the way to use "ref" keyword.

[Nerseus]

...it's also something you will rarely need to use (ref in C# or ByRef in VB).

For example, in ultraman's sample code it's not needed. Passing in the param without ref implies "By Value" but you can still change the Text property.

 

Now, if the param is a struct then you might want/need a ref param. I've rarely used structs (but I have) and more rarely needed to use ref on them.

 

-ner