|
tech
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Integer not incrementing in Windows Vista, is in XP Pro/HomeDim intA as Integer Dim intB as Integer dim myList as new List(Of String) intA = 10 intB = 20 .... code to fill the list .... intA = intA + 1 intB = intB + 1 Then I insert into a list of type String, like so: myList.Insert("the value being inserted here is " & intA, intB) On XP Pro/Home, the list inserts using intA = 11 and intB = 21. But on Vista, my beta users report that the Insert is using the previous values 10 and 20 respectively. I am unable to recreate this problem myself on Vista. Does anyone have insight as to why this is happening? Thank you in advance. Mike K wrote:
Show quote > I have a Net 2.0 app in VB that has code like this: You are certainly not.> > Dim intA as Integer > Dim intB as Integer > dim myList as new List(Of String) > > intA = 10 > intB = 20 > > ... code to fill the list .... > > intA = intA + 1 > intB = intB + 1 > > Then I insert into a list of type String, like so: > > myList.Insert("the value being inserted here is " & intA, intB) The Insert method takes two parameters, where the first is an integer and the second is a string. > On XP Pro/Home, the list inserts using intA = 11 and intB = 21. Without seeing some of the code that you are actually using, it's very > But on Vista, my beta users report that the Insert is using the previous > values 10 and 20 respectively. I am unable to recreate this problem myself > on Vista. > > Does anyone have insight as to why this is happening? Thank you in advance. hard to even have an idea about what's happening.
Show quote
"Göran Andersson" wrote: My mistake; I reversed the arguments of myList.Insert as I typed my > Mike K wrote: > > I have a Net 2.0 app in VB that has code like this: > > > > Dim intA as Integer > > Dim intB as Integer > > dim myList as new List(Of String) > > > > intA = 10 > > intB = 20 > > > > ... code to fill the list .... > > > > intA = intA + 1 > > intB = intB + 1 > > > > Then I insert into a list of type String, like so: > > > > myList.Insert("the value being inserted here is " & intA, intB) > > You are certainly not. > > The Insert method takes two parameters, where the first is an integer > and the second is a string. > > > On XP Pro/Home, the list inserts using intA = 11 and intB = 21. > > But on Vista, my beta users report that the Insert is using the previous > > values 10 and 20 respectively. I am unable to recreate this problem myself > > on Vista. > > > > Does anyone have insight as to why this is happening? Thank you in advance. > > Without seeing some of the code that you are actually using, it's very > hard to even have an idea about what's happening. > > -- > Göran Andersson > _____ > http://www.guffa.com > question. However the arguments' order are correct in my code. The main point is why the Insert method would use the integers' previous vakues. I've learned that the problem machine is running 64-bit Vista on a 64-bit dual-core machine. I am looking into whether dual-core is the problem or not. Mike K wrote:
> My mistake; I reversed the arguments of myList.Insert as I typed my If you did paste the actual code, it might be possible to spot the > question. However the arguments' order are correct in my code. > The main point is why the Insert method would use the integers' previous > vakues. problem right away. It might be a very simple mistake in the code, but as noone other than you can see the code, we're just guessing here. The code that you have written in the post is too incomplete to make any sense anyway. You are inserting an item at index 20 in an empty list, which is of couse not possible at all. Hello,
are you, by any chance, doing this stuff in paralell on multiple threads? If so, you must protect access to the list with some sort of locking mechanism (SyncLock statement in VB). Otherwise you might end up with a race condition which might or might not occur on a single processor machine. Kind regards, Henning Krause Show quote "Mike K" <Mi***@discussions.microsoft.com> wrote in message news:9128BCF0-6674-48A8-82D6-B557B5D7FB4E@microsoft.com... > > > "Göran Andersson" wrote: > >> Mike K wrote: >> > I have a Net 2.0 app in VB that has code like this: >> > >> > Dim intA as Integer >> > Dim intB as Integer >> > dim myList as new List(Of String) >> > >> > intA = 10 >> > intB = 20 >> > >> > ... code to fill the list .... >> > >> > intA = intA + 1 >> > intB = intB + 1 >> > >> > Then I insert into a list of type String, like so: >> > >> > myList.Insert("the value being inserted here is " & intA, intB) >> >> You are certainly not. >> >> The Insert method takes two parameters, where the first is an integer >> and the second is a string. >> >> > On XP Pro/Home, the list inserts using intA = 11 and intB = 21. >> > But on Vista, my beta users report that the Insert is using the >> > previous >> > values 10 and 20 respectively. I am unable to recreate this problem >> > myself >> > on Vista. >> > >> > Does anyone have insight as to why this is happening? Thank you in >> > advance. >> >> Without seeing some of the code that you are actually using, it's very >> hard to even have an idea about what's happening. >> >> -- >> Göran Andersson >> _____ >> http://www.guffa.com >> > > My mistake; I reversed the arguments of myList.Insert as I typed my > question. However the arguments' order are correct in my code. > The main point is why the Insert method would use the integers' previous > vakues. > > I've learned that the problem machine is running 64-bit Vista on a 64-bit > dual-core machine. I am looking into whether dual-core is the problem or > not. "Henning Krause [MVP - Exchange]" wrote: Henning, thanks for replying. The problem code is on the main thread. I do > Hello, > > are you, by any chance, doing this stuff in paralell on multiple threads? > > If so, you must protect access to the list with some sort of locking > mechanism (SyncLock statement in VB). Otherwise you might end up with a > race condition which might or might not occur on a single processor machine. > > Kind regards, > Henning Krause have another thread on which most my other methods run on, but they don't read or write the 2 problem integer variables. Even though it's on the main thread, I'll try wrapping the code in SyncLock anyway to see if that makes a difference. Thanks. Show quote > > > "Mike K" <Mi***@discussions.microsoft.com> wrote in message > news:9128BCF0-6674-48A8-82D6-B557B5D7FB4E@microsoft.com... > > > > > > "Göran Andersson" wrote: > > > >> Mike K wrote: > >> > I have a Net 2.0 app in VB that has code like this: > >> > > >> > Dim intA as Integer > >> > Dim intB as Integer > >> > dim myList as new List(Of String) > >> > > >> > intA = 10 > >> > intB = 20 > >> > > >> > ... code to fill the list .... > >> > > >> > intA = intA + 1 > >> > intB = intB + 1 > >> > > >> > Then I insert into a list of type String, like so: > >> > > >> > myList.Insert("the value being inserted here is " & intA, intB) > >> > >> You are certainly not. > >> > >> The Insert method takes two parameters, where the first is an integer > >> and the second is a string. > >> > >> > On XP Pro/Home, the list inserts using intA = 11 and intB = 21. > >> > But on Vista, my beta users report that the Insert is using the > >> > previous > >> > values 10 and 20 respectively. I am unable to recreate this problem > >> > myself > >> > on Vista. > >> > > >> > Does anyone have insight as to why this is happening? Thank you in > >> > advance. > >> > >> Without seeing some of the code that you are actually using, it's very > >> hard to even have an idea about what's happening. > >> > >> -- > >> Göran Andersson > >> _____ > >> http://www.guffa.com > >> > > > > My mistake; I reversed the arguments of myList.Insert as I typed my > > question. However the arguments' order are correct in my code. > > The main point is why the Insert method would use the integers' previous > > vakues. > > > > I've learned that the problem machine is running 64-bit Vista on a 64-bit > > dual-core machine. I am looking into whether dual-core is the problem or > > not. > > Mike K wrote:
Show quote > Putting a SyncLock around a single piece of code only has any effect if > "Henning Krause [MVP - Exchange]" wrote: > >> Hello, >> >> are you, by any chance, doing this stuff in paralell on multiple threads? >> >> If so, you must protect access to the list with some sort of locking >> mechanism (SyncLock statement in VB). Otherwise you might end up with a >> race condition which might or might not occur on a single processor machine. >> >> Kind regards, >> Henning Krause > > Henning, thanks for replying. The problem code is on the main thread. I do > have another thread on which most my other methods run on, but they don't > read or write the 2 problem integer variables. > > Even though it's on the main thread, I'll try wrapping the code in SyncLock > anyway to see if that makes a difference. > > Thanks. > more than one thread is using that code. If only the main thread is using that code, it doesn't make any difference. You can spend the time to try it, though. If it makes any difference, there are two possibilities. Either that more than one thread is using the code, which means that there is something wrong with your threads, or that it changed the execution time, which means that it's a race condition between threads.  |
|||||||||||||||||||||||
Other interesting topics