Vista x64 SP1

  • Thread starter Thread starter Nicolas Hinze
  • Start date Start date
N

Nicolas Hinze

Dear all,

I installed Vista SP1 on my Vista x64 Enterprise machine. Now my
Visual Basic 2005 (.Net 2) does not behave correctly. It appears that
'for loops' have a problem of some sort. For example, I have a 'for
loop' to fill a dropdown control with numbers from x to z. Now that
dropdown stays empty. This behavior did not happen before SP1. I do
not get any error messages. Everything works perfectly on WinXP.
Anyone has any idea if Vista SP1 break the .net 2.0 framework ?

Nick,
 
Actually, I pinpointed it to a change of behavior of the CurDir()
command. For some reason it is not returning the same between Vista
RTM and Vista SP1.
 
Actually, I pinpointed it to a change of behavior of the CurDir()
command. For some reason it is not returning the same between Vista
RTM and Vista SP1.
Click to expand...

Is your framework 64-bit one?
 
Dear all,

I installed Vista SP1 on my Vista x64 Enterprise machine. Now my
Visual Basic 2005 (.Net 2) does not behave correctly. It appears that
'for loops' have a problem of some sort. For example, I have a 'for
loop' to fill a dropdown control with numbers from x to z. Now that
dropdown stays empty. This behavior did not happen before SP1. I do
not get any error messages. Everything works perfectly on WinXP.
Anyone has any idea if Vista SP1 break the .net 2.0 framework ?

Nick,
Click to expand...

What about My.Computer.FileSystem.CurrentDirectory?

Thanks,

Seth Rowe [MVP]
 
What about My.Computer.FileSystem.CurrentDirectory?

Thanks,

Seth Rowe [MVP]
Click to expand...

The .Net Framework is the 2.0 32Bit. I develop on a WinXP 32Bit. I
just run my softweare on Vista 64Bit, because I can run more threads
and access more memory that way.

I was using CurDir() to get the directory that was opened with the
OpenFileDialog. Now I just use the substring of the opened filename.
There might be a more elegant option though. I was using CurDir,
because this sfotware was first developped in VB6. Here is my code:

Private Sub mnuFileOpenProject_Click(ByVal sender As Object, ByVal
e As System.EventArgs) Handles mnuFileOpenProject.Click

Dim sFile As String

Dim tempForm As Form
For Each tempForm In Forms
If tempForm.IsMdiChild = True Then
tempForm.Close()
End If
Next

Me.Text = "TSAM"

With OpenFileDialog1
.Title = "Open"
'ToDo: set the flags and attributes of the common dialog
control
.Filter = "All Files (*.prj)|*.prj*"
.ShowDialog()
If Len(.FileName) = 0 Then
Exit Sub
End If
sFile = .FileName
End With

If String.IsNullOrEmpty(sFile) = False And sFile <> "*.prj"
Then 'Skip if cancel is hit

Try
FileOpen(1, sFile, OpenMode.Input)
Input(1, ProjectName)
Input(1, ProjectDescription)
FileClose(1)
Catch ex As Exception
MsgBox(ex.Message, MsgBoxStyle.Critical, Me.Text)
End Try

Project_Dir = sFile.Substring(0, sFile.LastIndexOf("\"))
'CurDir()
Me.Text = "TSAM - " + ProjectName
Call LoadIntro()
TreeView_Load()

End If

End Sub
 
Nicolas said:
The .Net Framework is the 2.0 32Bit. I develop on a WinXP 32Bit. I
just run my softweare on Vista 64Bit, because I can run more threads
and access more memory that way.
Click to expand...

Can you?
I thought you had to specifically build your code to /target/ the x64
platform before you got any benefit from running on it - although I'd be
[very] happy to be proven wring on this. :-)
Dim tempForm As Form
For Each tempForm In Forms
If tempForm.IsMdiChild = True Then
tempForm.Close()
End If
Next
Click to expand...

I'd fully expect this code to /miss/ some of your open forms.

Because it's updating the collection of forms as it goes along (by
closing some of them), the iterator on that collection is going to get
confused. When doing this sort of thing, always loop /backwards/
through the values; indexing into them is far more resilient than using
"For Each".
For iSub As Integer = Forms.Count - 1 To 0 Step -1
Dim tempForm As Form = Forms( iSub )
If tempForm.IsMdiChild = True Then
tempForm.Close()
End If
Next
Click to expand...

One for the next version wish-list, maybe?

For Each variable [As type] In *Reversed* values

??

HTH,
Phill W.
 
Thanks for the coding tips Phill!

I'm running my 32Bit application on Vista 64Bit to be able to take
advantage of more memory. Now the application thread can only access
the standard 2GB or so. However, what I meant by threaded is that my
model can now call more .exe threads in the background and run much
faster. All is 32Bit, but when each of my .exe threads takes like 1 GB
each, I could only run a maximum of 2 or 3 threads in XP. Now in Vista
64Bit, with 8GB of RAM I can run 8 of those .exe threads at the same
time.

So to do this, you do not need to recompile in 64Bit.

Nick,
 
Nicolas said:
Thanks for the coding tips Phill!
Click to expand...

You're welcome.
All is 32Bit, but when each of my .exe threads takes like 1 GB
each, I could only run a maximum of 2 or 3 threads in XP. Now in Vista
64Bit, with 8GB of RAM I can run 8 of those .exe threads at the same
time.

So to do this, you do not need to recompile in 64Bit.
Click to expand...

Excellent.
OK, it may not be multi-/threading/ in the strictest sense, but with
that much space to run around in, your code ought to /fly/!

Regards,
Phill W.
 
Back
Top