C# Discussion Boards - CodeProject

Re: code complies blows sky high on button OK click

15-Sep-05 16:55

Anonymous wrote:
Problem_1: I enter NUMBERS(not letters etc...) into the text boxes and hit OK button--> Keep getting the MessageBox in the catch block.
i.e. bShowValue = false; ALL the time.

Use F9 to set a break point at the start of the function. Make sure you're in debug mode ( Build/Configuration Manager ), then hit F5 to start debugging. I believe it's F5 also to step to the next line, a right click will give you the option and show you the keys in any case.

Anonymous wrote:
If all drawing must be in paint method, perhaps it would be best to create an
array of pens INSIDE the paint method inside a for(...) loop? No?

Your paint method should be able to tell via a flag if it should draw a number, then call the draw method that you're calling now. Why do you need an array of pens ? If they are always the same, one pen should be a member variable ( which means you need to impliment IDisposable and dispose of it )

Christian Graus - Microsoft MVP - C++

-- modified at 22:56 Thursday 15th September, 2005

Anonymous15-Sep-05 18:18

Anonymous

15-Sep-05 18:18

Christian Graus wrote:
If they are always the same

They're not.I need many different colored lines, so each button click that is associated with the text boxes--> btn OK needs to effectively fire
g.DrawLine... w/ a different color.

thanks for your help! I will work on this....I'm sorry I'm so disorganized but I'm trying to learn this by trial and error....

Re: code complies blows sky high on button OK click

Christian Graus18-Sep-05 10:57

Re: code complies blows sky high on button OK click

18-Sep-05 10:57

Anonymous wrote:
They're not.I need many different colored lines, so each button click that is associated with the text boxes--> btn OK needs to effectively fire
g.DrawLine... w/ a different color.

It cannot work that way. You will need to store the information about what you want to draw, so that your paint handler can draw them correctly.

Christian Graus - Microsoft MVP - C++

Guffa15-Sep-05 19:18

Guffa

15-Sep-05 19:18

The problem is that you are throwing away all the information about the error. You are catching all possible exceptions and assumes that there is only one possible cause for the error.

If you want to catch the exception that occures when someone writes an illegal number, you should catch only that specific exception (FormatException). Although the better approach is to validate the data instead of using exceptions. Exceptions should only be used for errors that you can't handle, and faulty input is very much possible to handle.

Use the Double.TryParse method to make an attempt to parse the value. If the return value is false, the input is faulty, and you can very gracefully display the error message.

---
b { font-weight: normal; }

can't get variable into Watch Window?

Anonymous15-Sep-05 14:18

Anonymous

15-Sep-05 14:18

I'm trying to learn how to use the debugger.
I have the Watch Window out but it I can't seem to get any variables into it.
If I click on it it just turns blue.
If I copy the variable and the right-click paste into the window-- nothing...
help-- thanks
(Debugger is in "run", a breakpoint has been set..)
help! thanks...

Re: can't get variable into Watch Window?

Christian Graus15-Sep-05 14:20

Re: Problem with database

15-Sep-05 14:20

The watch window has tabs on the bottom. Click Immediate ( from memory ) to enter variables, otherwise it shows you what it can see in the current scope.

Christian Graus - Microsoft MVP - C++

Problem with database

kavicky15-Sep-05 13:49

kavicky

15-Sep-05 13:49

I have written code with a single database table with front end in c#.
I am able to make changes in table by using the update statment. But after i exit out of the application I am not able to login with the same user name and pwd that I could before.
Pasting my login page code and the update query code...can anyone help me plz

private void button1_Click(object sender, System.EventArgs e)

{
try
{

oleDbConnection1.Open();

oleDbDataAdapter1.SelectCommand.CommandText = "Select User, PIN
from BankAccount where User = '" + UsertextBox.Text + "'"+
" And PIN= '" +
PINtextBox.Text + "'";

oleDbDataAdapter1.Fill(dataSet1);

DataTable datatable=dataSet1.Tables[0];

if(UsertextBox.Text == (string)datatable.Rows[0][0] && PINtextBox.Text== (string)datatable.Rows[0][1])

{
string user= UsertextBox.Text;
AccountForm Af = new AccountForm(user);
Af.Show();
}
else
{
label1.Text="Invalid User Name or Password";
}

}
catch(System.Data.OleDb.OleDbException ole)
{
MessageBox.Show( ole.ToString());
}
finally
{
oleDbConnection1.Close();
}
}

And in the second form I have this Update query method

private void button3_Click(object sender, System.EventArgs e)
{

try
{
oleDbConnection1.Open();

if( Acc_textbox.Text != " ")

{

int creditbalance = Int32.Parse(textBox3.Text);
//label7.Text=creditbalance.ToString();

oleDbDataAdapter1.UpdateCommand.CommandText=
" Update BankAccount SET " +
"FirstName = '" + textBox2.Text+
" ', LastName ='"+ textBox1.Text+
"', IntialBalance = " + creditbalance+
" , PIN ='"+ textBox4.Text+
" ', PhoneNumber= " + Int32.Parse(textBox5.Text)+
" , Address ='"+ textBox6.Text+
" ', City ='"+ textBox7.Text+
" ', State ='"+ textBox8.Text+
" ', SSN ='"+ textBox9.Text+
" ' where User = '" + Acc_textbox.Text + "'";

statustextbox.Text += "\r\n Sending Query "+
oleDbDataAdapter1.UpdateCommand.CommandText + "\r\n";

oleDbDataAdapter1.UpdateCommand.ExecuteNonQuery();
statustextbox.Text +="\r\n Query Successful";
}
else

statustextbox.Text +="\r\n Query not Successful";

}
catch(System.Data.OleDb.OleDbException ole)
{
statustextbox.Text += ole.ToString();
}
finally
{
oleDbConnection1.Close();
}

}

Christian Graus15-Sep-05 14:23

Event handlers in multi-threaded apps

15-Sep-05 14:23

What does your database look like at the end ? Has your username/password been changed or lost entirely ?

Why on earth do you have only one table ? You may as well persist to XML if you're going to do that.

Your code is also extremely vunerable to SQL injection attacks. Using stored procedures instead of this sort of SQL on the fly generation would help your overall design, but would not be enough by itself to provide protection from attacks.

Christian Graus - Microsoft MVP - C++

brucemo15-Sep-05 13:32

15-Sep-05 13:32

I'm a C# noob so I apologize if I say something stupid or unclear.

I have a class that contains a thread that sits there in a loop, considering the world. Every once in a while, it decides that it needs to alert the world to some idea it has, so it calls its delegate function, sends information to all of its clients, who get the information via event handler functions that they've "+="'d to the delgate.

If this class didn't incorporate a thread, I would be done here, and everything would work perfectly. My class's clients would add a handler to the class's delegate when they feel like listening to it jabber, and they would periodically receive data and do whatever they want with it.

The terrible problem is that you can't ordinarily mess with controls if you aren't in the control's originating thread, so you need to use "Invoke".

If I understand correctly, one way to deal with this would be to have all the clients realize they are dealing with a class that is kind of toxic, and have all handlers that sign up with my class call "Invoke" whenever they are called. Essentially, the clients would realize that they are operating from within a foreign thread, and they would take appropriate precautions.

I don't like this solution, because the clients shouldn't have to know that they are being called from a different thread. They should just be able to add a handler and get data from the class, and everything should work.

Also, I could have some performance issues here, since future instances of my class might not use a thread, and I'd be stuck with all of this old ugly code that uses "Invoke".

Another way to deal with this is for the class itself to use "Invoke" on the delegate. I haven't thoroughly tested this, but it compiles and apparently runs, at least when there is only one client.

The drawback to this is that when I create the class, I have to pass in the form that created the class, so there will be an object to use to call invoke. This is ugly, and also I expect it would mess up if another thread added a handler to my class.

Question:

What is the best way to deal with events that are generated from within a thread, so that the clients work correctly, don't have to know that they are dealing with a thread, and don't have to pass difficult to explain parameters around?

Thank you,

bruce

brucemo15-Sep-05 13:57

15-Sep-05 13:57

Can I just use the "BeginInvoke" method on the delegate, and dummy out the 2nd and 3rd parameters? This is what I'm doing now, and it also compiles and runs.

bruce

brucemo15-Sep-05 14:35

15-Sep-05 14:35

Okay, this idea is wrong, I can see it coming in on a different thread.

bruce

Judah Gabriel Himango15-Sep-05 15:27

Judah Gabriel Himango

15-Sep-05 15:27

You can subscribe to an event from a different thread. You just cannot use a System.Windows.Forms.Control from a thread other than the UI thread.

Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Cops & Robbers
Judah Himango

leppie15-Sep-05 16:12

leppie

15-Sep-05 16:12

Create a generic event invoker, something like this:

ISynchronizeInvoke s;

void InvokeEvent(Delegate ev, param object[] args)
{
  if (s.InvokeRequired)
  {
    s.Invoke(ev, args);
  }
  else
  {
    ev.DynamicInvoke(args);
  }
}

^{xacc-ide 0.0.15 now with C#, MSIL, C, XML, ASP.NET, Nemerle, MyXaml and HLSL coloring - Screenshots}

brucemo15-Sep-05 17:07

15-Sep-05 17:07

I'll describe it a little differently.

I have a black box. Code subscribes to the black box by adding event handlers to the delegates that are the visible interface of the black box.

Maybe the black box uses threads, and maybe it doesn't. It's a regular class now but eventually it will be an interface class, and some of the derived classes I have in mind will not use threads. In any case, the subscribers ideally should not have to care. They should just sit back and wait, and when their event handlers fire, they should fire in the same thread that they are sitting in, because doing otherwise is about as polite as dumping coffee in their lap.

The generic event invoker you provide would work. It's pretty much what I do now, but the problem is that ISynchronizeInvoke object. As far as I know I can't make one of those on the fly. I have to pass one in, probably as an argument to the constructor of the black box. And unless I am misunderstanding C# reality, which is certainly likely since I have been doing C# for about a week now, the one I pass in won't necessarily apply to all of the events attached to the delegate.

I think that I have two choices:

1) Do it as you suggest, which results in a "control" or "form" parameter being passed in to my black box, and which results in my being able to accept customers from one thread only.

2) Make sure that all of the black box customers are aware that I'm going to stab them in the eye by calling into their event handler code from a different thread. This is weird and unpleasant code, but it would work, and the black box itself is clean.

I think I would lean toward the first solution, because the oddball code is in the black box, where it where it should be.

I wish there was another solution -- that it was possible to call a delegate in such a way that all of the event handler calls magically found their way back to the correct thread.

Thank you again,

bruce

Andy Brummer15-Sep-05 17:38

Andy Brummer

15-Sep-05 17:38

Look at System.Timers.Timer to see how the CLR developers dealt with the problem. I'm not saying it's a great solution, but this is essentially what the "standard" solution to the problem is.

The way I view it is that thread safety is part of an objects interface or contract. There is just no way around it, there is just too much overhead with making every object thread safe to make it a default.

I can imagine the sinking feeling one would have after ordering my book,
only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon

brucemo15-Sep-05 21:29