I press a button2 to display a form2 (which displays as topmost)
Then ill press button3 to close form2 and display form3 (form3 also display as top most) and this works fine.
However...if say i have form2 open and i press button4 to display form4, then close form4, and then press button3 (which closes form2 and siplays form3) what happens here instead is that form3 displays BUT form2 does not close.
this is the sort of code im using
f = New Form2
Was hoping somebody maybe able to help me with this problem.
My guess is that based on the little code you posted you are using 'f' to represent the open form. So you press button2 and 'f' gets set to form2 which is then shown. When you press button3, you call f.close which closes form2 then you set 'f' to equal form3. However, the problem is that when you open form4 which you probably set 'f' equal to, you don't close form2. Now 'f' references form4 not form2. So when you click button3 and call f.close it try's to close form4 which is actually already closed.
I am getting following error when hit the update button.
No error message available, result code: DB_E_ERRORSOCCURRED(0x80040E21).
Any idea Why? thanks.
here is my code:
Private Sub btnupdate_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnupdate.Click
Dim data As New DataSet
Dim dbConn As OleDb.OleDbConnection
Dim dataAdapter As OleDb.OleDbDataAdapter
Dim connectionString As String = "Provider=sqloledb;Data Source=A45292\SQLEXPRESS;Initial Catalog=FSS;Integrated Security=True"
Dim sqlString As String = "SELECT * FROM [Caller Records] Where RecordNo =" & TextBox2.Text
dbConn = New OleDb.OleDbConnection(connectionString)
dataAdapter= New OleDb.OleDbDataAdapter(sqlString, dbConn)
dataAdapter.Fill(data, "Caller Records")
Dim tbl As DataTable
tbl = data.Tables("Caller Records")
Dim selectedRows() As DataRow
selectedRows = tbl.Select("RecordNo = " & TextBox2.Text)
If selectedRows.Length > 0 Then
selectedRows(0).Item("FirstName") = FirstNameTextBox.Text
selectedRows(0).Item("LastName") = LastNameTextBox.Text
dataAdapter.Update(data, "Caller Records")
First, why are you using the Ole data providers when your using a MS SQL Server? Use the Sql Server providers (SqlConnection, SqlCommand, Sql...) for better performance.
Next, you're retrieving all this data just to find a record and write it back when you don't have to. The DataSet object that you filled with your DataAdapter already has this data in it. If the textbox's are bound to the DataSet, the updates have already been made. Just call the Update method on your DataAdapter and it'll write the changed records back to the database. Just about all of this code is unnecessary.
I'm looking for a reasonable way to avoid the serialization of events/eventhandlers in VB.NET (2005).
Since the structure of the objects I wanna serialize is quiet comlex, removing before and re-adding all handlers after the serialization could generate new problems.
Is there any solution except moving to C# or implementing ISerializable?
Thanks guys for the replay!
Since I have some COM stuff included I'm afraid to be forced to use the binary formatter. So <xmlignore> will probably not work.
What I further need is an abstract soution since the project I'm working on is a kind of a framework. Using any 'object specific' implementation could end up in a mess.
I have had seen the link Dave mentioned before I posted this message and I was hoping that there might be an easier way.
It's really a shame.
I am trying to convert a string representation(2007-02-22) into a dateformat yyyyMMdd. it returns the right result as string but I want the returned type as date and in this format 2007-02-22 as XML API I am using requires a DATE not STRING representation like this.
Am I missing something very easy here (quite possible)?
Did I get it right that you have a string representation of a date and want to convert this into a DateTime instance.? If so, then take a look at the DateTime.TryParseExact or DateTime.ParseExact (framework < 2.0) methods. Both methods let you specify a custom format for the input string.
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook
Normally, you'd place the .Flush/.Close and .Dispose in the Finally block. You'd first check to see that the stream is indeed open before you called Close on it, then Dispose it.
Why? Because your code could throw an exception before or during the file open, so it's possible that the file never gets opened. Also, it's possible that your code could throw an exception during the manipulation of the file, leaving the file hung open in the Catch/Finally handlers. Finally gets executed no matter what happens in the Try block, so checking and closing the file in the Finally block is the best place to do it.
Dim sw As StreamWriter
sw = New StreamWriter(filePath)
For x As Integer = 1 to 100
Catch ex As Exception
' used a 'catch all' Exception which is not really good practice!!
' You'll only get a StreamWriter object if the file was successfully opened!
If Not sw Is Nothing Then
Now in place of that, with VB.NET 2005, you can instead use the Using keyword to do the same thing. When the code execution leaves the Using block for any reason the object created on the Using line is automatically closed Disposed.
Using sw As StreamWriter = New StreamWriter(filePath)
For x As Integer = 1 to 100
Catch ex As Exception
If you're writing to all 5 files for each record you write, no there isn't unless you turn off the automatic formatting in Tools/Options. But do that also turns off the formatting for every file in every project you open from then on.
If your picking which file you are going to write to for each record, then create a StreamWriter when you need to write to that particulare file. Don't open the file(s) unless you need to write to it. But, there is a performance penality for doing this, so you might want to test it before you nail it down as production code. But, if you sacrifice performance just to make the code "look pretty", I'll frown up you if you ever end up on my team...
Basically, no there isn't. It's not so bad. I've seen C++ and C# code indented 20-30 levels deep because of nested IF's and loops. It happens...
You're saying there is a performance hit to open the file everytime you need to write to it or to open 5 and write if you need to when you need to until you are done and then closing them all?
Yes, there is a performance penalty for opening and closing a file. Try it. Write a little app that opens a file, writes 10,000 lines of text to it, then closes it. Then rewrite that loop so it opens the file, writes a line to it, then closes it, 10,000 times. See which one runs faster.
checking for nothing establishes if it is ok to Flush and Close?
You're checking to see if it is safe to call Flush and Close, and even Dispose, on that object. If that object is Nothing, then any call you make on it will result in a Null Reference Exception.
are you saying I could simply call .Dispose and it would take care of the Flush/Close instead of me calling those 2 in addition to the .Dispose?
Dave Kreskowiak Microsoft MVP - Visual Basic
Last Visit: 31-Dec-99 19:00 Last Update: 1-Feb-23 11:45