A Design question [offtopic?] - C# Discussion Boards

Re: Procedure Parameter Pointer

25-Jan-05 11:24

Hi,

Could anyone help me? I want to know what happen to parameter variable when a procedure/method is invoked. Is it static allocation or dynamic allocation? Is there a way to get parameter pointer?

Thx.

Dennis C. Dietrich25-Jan-05 12:13

Dennis C. Dietrich

25-Jan-05 12:13

mineminemine wrote:
I want to know what happen to parameter variable when a procedure/method is invoked. Is it static allocation or dynamic allocation? Is there a way to get parameter pointer?

If you have a method that takes a struct as its parameter it will receive a copy of the struct. If it takes a non-struct object it will receive a new object variable pointing to that object (remember, an object variable is a pointer). However, you can use the ref[^] (or out[^]) keyword to let the method access the original struct/object variable. Of course you can also use pointers in C#[^] directly if you declare your code as unsafe[^] but I recommend to avoid this whenever it's possible.

Best regards
Dennis

A Design question [offtopic?]

moredip25-Jan-05 11:03

moredip

25-Jan-05 11:03

Hi all, I posted this on the General Discussion board, but it seems a little dead in there. Hopefully this isn't too offtopic for this board.....

I was hoping for some advice on 'best practices' regarding the design of an app I'm working on. It's a subscription-based web app in C#. Member data is stored in a DB table cunningly named Members. I've implemented a fairly simple Member class which essentially wraps access to a row in the table, with functions like:

static public Member FetchFromDB( int iMemberID );
public void UpdateInDB();
etc.

and getters/setters to map the contents of the Members row, like:
public DateTime ExpiryDate{ get{ return _expiryDate; } }
public StatusEnum Status{ get{ return _status; } }
etc.

I'm happy with this class as described so far. It does one job, maintains a constant level of abstraction/encapsulation, etc. However, My app also needs functionality like 'Check whether a member's ExpiryDate is in the past, and if so update their Status to Expired', or 'Update LastOnline to now'.
The way I've been doing this so far is to add methods to Member such as UpdateLastOnlineToNow(), CheckExpiryDate(), etc. Obviously this works fine, but I'm finding myself adding more and more 'utility' methods to Member, and I'm starting to think that Member has a 'bad smell' - it's still a wrapper for the DB, but it's also getting more and more higher-level functionality mixed into it.

This class is just an example, I'm also getting similar bad smells with various similar classes in my app (Message, for example, which encapsulates my message sending/receiving system).

So my question is, what do all you wise and esteemed CPians think? Have I been reading my Patterns books a bit too religiously? If I not, what would be the best way to refactor this? One thought I had is to break Member out into 3 classes, a low-level wrapper to the DB, a high-level wrapper that uses the low-level wrapper internally, and a utility class that also uses the low-level wrapper. Is this overkill?

Any other suggestions (or any thoughts at all) gratefully appreciated!

Cheers,

Pete

Skynyrd25-Jan-05 12:01

Skynyrd

25-Jan-05 12:01

I suppose it all depends on the coder's style. I'd do it this way:

1. I would create a Member class which would be an abstraction of a "real life" Member, or in other words, a Member object. It would have all the cunningly named strongly typed properties like string Name, int Id, date ExpirationDate, etc, and not much else. U could even make it a struct, but if it gets passed around a lot, it might be better to keep it as a class.

2. Then I would create a DBManager Class that would fetch, insert and update Member instances from/into the DB. This would be like your barebone original Member class but all methods/properties would be strongly typed to the Member class when necesarry:

public Member GetMember(int memberId)
{
   //Implmentation
}

public void UpdateMember(Member changedMember)
{ 
   //Implementation
}
etc...

3. And finally I would create a utility class that would perform all the functionalities upon the Member instances such as the ones you mentioned above: "UpdateLastOnLine", etc. All changes in the member instance would then be updated into the DB through the DBManager.

public void UpdateLastOnLine(Memeber member)
{
   //Implmentation
}
etc...

Hope this helps....if not quite your coding style, it might still give u some ideas. It might be an overkill for the true requirements of your app, but I always try to make my stuff in a orderly and structured fashion, even if its really not necessary.

moredip25-Jan-05 12:19

moredip

25-Jan-05 12:19

Hi Skynyrd,

Thanks for the response.

To clarify, the DBManager would just be responsible for wrapping the Member table in the DB, or wrapping all the tables?

I'm also not sure how the coupling would work with the three classes you mention. The way I see it, Member should be hiding/abstracting over some of the internal properties of a Member. For example, LastOnline shouldn't be settable, it should just be updatable to DateTime.Now. That being the case, both DBManager and the utility class would need access to the internals of Member, and I'm not sure how best to accomplish that. That was why I thought of having a low-level wrapper (which would expose those internals), and then a higher-level wrapper, which would be, as you say, a Member 'object'. But with that design, I'm not sure if it's feasible to have a seperate utility class. The utility class would need access to the internals, but the client of the utility class presumably wouldn't be able to access them. If this were C++, I'd consider making the utility class a friend of the lower-level wrapper, but AFAIK that isn't possible in C#.

I hope you don't think I'm being argumentative about this, I'm honestly just trying to figure the best way to design this sucker. I do appreciate your input!

And yes, as you say, all of this probably /is/ overkill for the app, but like you I like to try and keep my design as clean as possible (within reason!).

Cheers,

Pete

Skynyrd25-Jan-05 12:47

Skynyrd

25-Jan-05 12:47

DBManager could be used for wrapping all tables in the DB. If ur only updating and selecting, u could still keep the class public interface pretty simple and wrap all tables. It also depends on how u are encapsulating other objects equivalent to Members. U could even use a generic object and through Reflection and Attributes obtain the properties of the objects that represent fields in your underlying DataBase tables and thus create a very decoupled DB Manager with signatures like: Update(object changedRegistry) etc. (U could create a custom TableFieldAttribute(string fieldName) to mark the properties that represent real fields in the DB tables in order to acheive this...this comes in handy if u expect using additional properties in these objects that dont necessarily represent underlying fields).

Concerning the threeway implementation, ur right about the LastOnline method, this is probably where overkill comes in :p. The utility class would not be really necessary if only these type of methods appear. Maybe u could keep the implementation to just two classes (DBManager and Member) and Member would take care of methods similar to LastOnline, as it is logical that only Member should have access to the LastOnline setter. On the other hand, if some utilities require extensive work with Member instances then the threeway solution would be plausible, keeping methods like LastOnline in the Member class as a tool for the Utility class.

moredip25-Jan-05 13:45

moredip

25-Jan-05 13:45

I think the DBManager concept is interesting, particularly the use of Reflection and Attributes. However, I think it /would/ be overkill in this case Smile | :)

Also, it could get complicated for certain things - e.g. the Member table contains pictures, which I don't want to fetch every time I get member info. Obviously, the DBManager concept could be extended to cover that kind of thing, but then we're certainly deep in overkill land.

The reservations I have with the design you suggest is that I'm still left with a Member class that's got various levels of abstraction. While on the one hand it's exposing simple getter/setters, and it's also doing higher-level abstraction utility functionality - e.g. UpdateLastOnlineToNow(), CheckExpiryDate(), UpdateWithInputFromWebForm() (I should have mentioned that one earlier I guess).

Any other suggestions Wink | ;)

No, seriously, thanks for the input. It's been helpful. Keep it coming Wink | ;)

Cheers,

Ptete

COM Port in Visual C# 2005

Anonymous25-Jan-05 21:56

Anonymous

25-Jan-05 21:56

I'm not sure that the Member class should not be able to perform some simple higher-level abstraction utilities. If the actions are solely meaningful to the member class, then there is no problem in implementing them in that class.

For example, LastOnline and CheckExpiryDate might be only meaningful to the member class. Thus it would be reasonable to implement it in that class, even if its a higher level abstraction. Particularly, I would implement the CheckExpiryDate() as a boolean property HasExpired (question of tastes here Big Grin | :-D

).

On the other hand, more general functionality like UpdateWithInputFromWebForm might be a more general utility that might be meaningful to more objects than Member instances and should be implemented in a Utility class. My first design wouldnt be valid anyhow, as the Utility class should not be strongly typed to the Member class, and the update could and should be done in a generalize way (again with Reflection through a Dictionary collection: property name - new value for example u could acheive this)

To make it short, what I always try to do is isolate all DB Management from the real objects I'm using in my application. In your original design, your Member class was implementing the DB update logic too, and I think thats where I would change the abstraction of the objects. Implementing the utility class depends again on how complicated your app is really going to be, but I dont think implementing high level abstractions in the Member class is a design fault if those utilities are only applicable to the Member class.

I think we need some second view about this, so any more suggestions are welcome Smile | :)

Juan Pablo G.C.25-Jan-05 9:08

Juan Pablo G.C.

25-Jan-05 9:08

There's a new possibility in the System.IO that is accesing to Port Coms: System.IO.Ports, I'm not good with delegates and I'm trying to make a program that when receives a data from the serial port makes an event:

 private void Form1_Load(object sender, EventArgs e)<br />
        {<br />
            ptocom.ReceivedEvent +=new SerialReceivedEventHandler(ptocom_ReceivedEvent);<br />
   //It's not complete but I dont know how to put it well     <br />
}<br />
<br />
        void ptocom_ReceivedEvent(object sender, SerialReceivedEventArgs e)<br />
        {<br />
            //Type tipo; ?<br />
            //tipo = e.EventType.GetType(); ?<br />
            <br />
            //taken.Text = tipo.ToString(); ?<br />
            //taken.Text = buffer;<br />
            //throw new NotImplementedException(); <-thats appear automatic ?<br />
        }<br />
<br />
        private void button1_Click(object sender, EventArgs e)<br />
        {<br />
            SerialPort ptocom = new SerialPort("COM1", 9600, System.IO.Ports.Parity.None, 8, StopBits.One);<br />
            string buffer = "j";<br />
            ptocom.Open();<br />
            ptocom.ReadTo(buffer);<br />
        }

Thats all I could discover about using this new possibilities but It doesnt work, any Idea?

Juan Pablo García Coello. Electronic Engineer.
Projectist at the Electronic Dept.Instituto de Astrofísica de Canarias. Spain

Re: COM Port in Visual C# 2005

Stefan Troschuetz25-Jan-05 21:41

Stefan Troschuetz

25-Jan-05 21:41

I think your problem is, that you subscribe your event handler during the handling of the Form.Load event, but the SerialPort object isn't created until button1_Click gets called or more likely is newly created there, cause otherwise the handler subscription would crash with null reference exception.
So your event handler isn't subscribed to the SerialPort object you create in click event handler and therefor doesn't fire, but to some instance created before the Form.Load event.

www.troschuetz.de

COM Port in Visual C# 2005

Juan Pablo G.C.25-Jan-05 9:06

Juan Pablo G.C.

25-Jan-05 9:06

 private void Form1_Load(object sender, EventArgs e)<br />
        {<br />
            ptocom.ReceivedEvent +=new SerialReceivedEventHandler(ptocom_ReceivedEvent);<br />
   //It's not complete but I dont know how to put it well     <br />
}<br />
<br />
        void ptocom_ReceivedEvent(object sender, SerialReceivedEventArgs e)<br />
        {<br />
            //Type tipo; ?<br />
            //tipo = e.EventType.GetType(); ?<br />
            <br />
            //taken.Text = tipo.ToString(); ?<br />
            //taken.Text = buffer;<br />
            //throw new NotImplementedException(); <-thats appear automatic ?<br />
        }<br />
<br />
        private void button1_Click(object sender, EventArgs e)<br />
        {<br />
            SerialPort ptocom = new SerialPort("COM1", 9600, System.IO.Ports.Parity.None, 8, StopBits.One);<br />
            string buffer = "j";<br />
            ptocom.Open();<br />
            ptocom.ReadTo(buffer);<br />
        }

Re: COM Port in Visual C# 2005

warnerja26-Jan-05 12:09

warnerja

26-Jan-05 12:09

Duplicated here: http://www.codeproject.com/script/comments/forums.asp?forumid=1649&tid=1023891&exp=1&select=1023891#xx1024239xx[^]

Hierachy on windows without MDI

jpgarcia25-Jan-05 8:57

jpgarcia

25-Jan-05 8:57

I'm a non expert programmer and well I'm making a program that reads from a file how many 'child' 'style1.cs' windows to open (gets a name for each one from it).

1.- So how can I create N windows 'style1.cs'?, I mean,
style1 c_1 = new style();
and being accesible for ALL the Form1 code when on_load, because if I put

public void Form1_Load(object sender, EventArgs e)
{
//Read window number and name
style c_1 = new style();
//Read window number and name
style c_2 = new style();
}

it doesnt work.

1,5.- An embarrasing question, how can I made a for loop to do it with c_x?

2.- Can I made hierachy for 'style1' windows with the Form1 without MDI, because some things as moving it with non-border doesnt work. I mean, something like
c_1.Parent = this; //non MDI (written in Form1.cs)
...
int x= c_1.Parent.Location.X; //(written in 'child'.cs)

NOTE: I dont want to use FindWindow AND because FindWindow cant be never a solution for the same program, and other, I'm sure that there is a new function in c# in some System... to do that.

Thanks for reading,

Juan Pablo García Coello. Electronic Engineer.
Tenerife, Spain.

event handling

rchokler25-Jan-05 7:18

rchokler

25-Jan-05 7:18

i made new form named form1
inside i added label1
and panel1
inside the panel i made dynamic CONTROLBOXES each is abutton ( i mean add some buttons with small loop)

i wand to hide label when click event occurs on one of the buttons

Label.visible = off

this on the click event gives me the controlBox not the form
this is the main problem.

please help me how can i know who is the father of button and who is the father of panel ???
(do i have to sent this (of the form) for each button ??

Re: event handling

Stefan Troschuetz25-Jan-05 21:25

Stefan Troschuetz

25-Jan-05 21:25

Where did you define the event handler for the Click event? If it's defined inside your form1 class, the this keyword should give you access to the current instance of form1.
Anyway, to get the parent container of a control simply use its Parent property.

www.troschuetz.de

Speed Hack

Budi Zhu25-Jan-05 6:30

25-Jan-05 6:30

Hi, everyone!

Does anyone know about speed up programs or sometimes calles speed hack for games? I just want know how makes a such program. Could someone explain the basic concept?

Alex Korchemniy25-Jan-05 6:39

Alex Korchemniy

25-Jan-05 6:39

There are some programs that claim to improve performance. None of them work. Windows knows how to manage memory properly to get the best performance. The basic concept of a "performance booster" app is to move memory around so that you have more physical memory available. Although this might help once in a while you'll get bottlenecks when you switch to a different app that has been transfered to the PF. So basically its best to leave everything to Windows and design your apps to perform well in the first place.

This posting is provided "AS IS" with no warranties, and confers no rights.

Alex Korchemniy

Budi Zhu25-Jan-05 7:22

25-Jan-05 7:22

Thanks Alex. How about some programs that makes your applications "faster". For example speedhack programs that makes your games run faster: hit faster, run faster.

Dave Kreskowiak25-Jan-05 8:26

Dave Kreskowiak

25-Jan-05 8:26

I think your talking about "trainers"? Good luck, cause what your doing is poking numbers directly into the memory space of the game itself. There are no document (from a reliable source, anyway) that will teach you how to do this. It's sort of a black art that you figure out on your own.

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

Budi Zhu25-Jan-05 11:27