code file

  • Thread starter Thread starter GS
  • Start date Start date
G

GS

I would like refactor up the user control file into a couple of files of
logically grouped members.


I managed to split all excel related function and members into the code file
named excelUtil.cs with the same partial class name. no problem there.

However when I try to refactor further groups of members into another code
file in the same manner, members in the new file just can't access any
controls.


what gives? Do I have to start a new class and instantiate to use?
 
sorry, apparently the solution was somehow corrupted. clean and build the
solution cleared the problem
 
GS said:
I would like refactor up the user control file into a couple of files of
logically grouped members.

I managed to split all excel related function and members into the code file
named excelUtil.cs with the same partial class name. no problem there.

However when I try to refactor further groups of members into another code
file in the same manner, members in the new file just can't access any
controls.

what gives? Do I have to start a new class and instantiate to use?
Click to expand...

Without an actual code example, it's impossible to say what you might be
doing wrong. But, partial classes are not limited to two files, so the
basic idea of what you say you want to do should work fine.

That said, you really shouldn't use partial classes that way. Their
main purpose is to support IDE designers, to allow user extensions of
designer-generated code without requiring the user to edit the code file
that the designer is manipulating.

If you are finding your class so large that you want to refactor it in
this way, it is better to refactor it into different classes. As an
example, a sub-class of System.Windows.Forms.UserControl really has no
reason to have _any_ Excel-specific code in it at all. So, if you have
"Excel-related members" in the type, those really belong in a completely
different class.

That class may in turn be used by your UserControl class, or more likely
they ought to be used by some other class that somehow connects the
UserControl and the Excel-specific stuff. Of course, I can't provide
specific advice as to the best way to refactor the code, not knowing any
details whatsoever about the actual code. But hopefully you get the
general idea.

The bottom line is that, when you feel like your class is getting too
large for one file, that's when your class most likely is too large to
be one class.

Pete
 
thx

I do like the idea.


however how can I code the new class so it sort of autoinstantiate itself
w/o
mynewclass myinstance = new mynewclass()
 
GS said:
thx

I do like the idea.


however how can I code the new class so it sort of autoinstantiate itself
w/o
mynewclass myinstance = new mynewclass()
Click to expand...

Unfortunately, you have not provided sufficient context to understand
that question.

It's possible that the code that will be refactored out of the
UserControl class works well simply as a static class. Then no
instantiation is required.

Alternatively, perhaps you need to implement an interface, or otherwise
pass an object reference of the class to some other code. In that case,
perhaps writing the class as a singleton would be more appropriate.

If neither of those options seem to fit your needs, then you're stuck
creating an instance of your class _somewhere_. Without knowing what's
wrong with simply allocating a new instance of the class with the "new"
operator, it's impossible to suggest alternatives (other than the very
general ones above).

Pete
 
Back
Top