Writing to a sequential file from various child forms

  • Thread starter Thread starter Cashewz
  • Start date Start date
C

Cashewz

Using a menu item to write to a sequential file from the parent form, what
code and where would I put it to write the text values, settings, bool
values from various child menues?
 
Using a menu item to write to a sequential file from the parent form,
what code and where would I put it to write the text values, settings,
bool values from various child menues?
Click to expand...


Can anyone help? Please??
 
Cashewz said:
Using a menu item to write to a sequential file from the parent form, what
code and where would I put it to write the text values, settings, bool
values from various child menues?
Click to expand...

I'm not entirely clear on what you're trying to do.

Your menu item, as defined in a "Parent Form" wants to write "values" to
a text file. So far, so good. StreamWriters are your friend here.

Don't put this code into the Click Event handler for the menu item.
Add a method to your Form that does this work and call that from the
menu item.

If you're working with /inherited/ Forms, make the method "Protected"
rather than "Private".

If necessary, code this method to iterate [recursively] through the
contents of the MainMenu property of the Form but, if you're doing what
I /think/ you're doing, I'd recommend coding for each relevant item
manually.

HTH,
Phill W.
 
Cashewz said:
Using a menu item to write to a sequential file from the parent form,
what code and where would I put it to write the text values,
settings, bool values from various child menues?
Click to expand...

I'm not entirely clear on what you're trying to do.

Your menu item, as defined in a "Parent Form" wants to write "values"
to a text file. So far, so good. StreamWriters are your friend here.

Don't put this code into the Click Event handler for the menu item.
Add a method to your Form that does this work and call that from the
menu item.

If you're working with /inherited/ Forms, make the method "Protected"
rather than "Private".

If necessary, code this method to iterate [recursively] through the
contents of the MainMenu property of the Form but, if you're doing
what I /think/ you're doing, I'd recommend coding for each relevant
item manually.

HTH,
Phill W.
Click to expand...

Thanks. The book i'm dealing with is, in my opinion, quite poor to learn
from: Advanced Programming with Microsoft, Visual Basic .NET, A case-
based approach by "Bob Spear". My teacher, nice woman that she is, isn't
the hands-on type. She doesn't put examples out on the class web page,
and the once a week class goes over the topics AFTTER they have been
assigned (and are due).

In any case, i'm now learning to love setting public variables in a
module for all my child-parent variable needs. ;)
 
In any case, i'm now learning to love setting public variables in a
module for all my child-parent variable needs. ;)
Click to expand...

I find it is generally best to avoid public class members, and instead
access them through properties. Properties are a nicer way of handling
getter/setter code, and I usually add input validation into any set
procedure, to make sure that any values passed are OK, and to take any
extra action that needs to be done.
 
Just to add one other item to the list.

It makes debugging much easier. Using properties allows the setting of
breakpoints while debugging to sort out the "who set that value" problem.

LS
 
Cashewz said:
In any case, i'm now learning to love setting public variables in a
module for all my child-parent variable needs. ;)
Click to expand...

Good for you.

Now, go and slap yourself [hard] around the face a few times and stop
doing this.

"Public Variables in a Module" = "Global variable".

These are Bad.

The Good You can access them from anywhere in your project and set them to any
value you want, whenever you need to.

The Bad news.
You can access them from anywhere in your project and set them to any
value.

As an [artificial] example:

Module Globals
Public MonthAbbrevs As String () = { "Jan", ..., "Dec" }
Public Month as Integer = 2
End Module

Class X
Public Sub New()
Console.Writeline( Me.GetMonthname() ) ' OK
Me.SomeMethod()
Console.Writeline( Me.GetMonthname() ) ' BOOM
End Sub
Private Sub SomeMethod()
Globals.Month = 77
End Sub
Private Function GetMonthname() As String
Return Globals.MonthAbbrevs(Globals.Month - 1)
End Sub
End Class

At the very least, wrap your "globals" in Properties; that way you can
protect against this kind of corruption and, if you /do/ start getting
some odd values appearing unexpectedly, you can pop a breakpoint in the
Property to find out /where/ the dodgy data is coming from - try doing
the same with just a global variable!

Regards,
Phill W.
 
Back
Top