Nope. I'm not comprehension-impaired, either.

Post #155,342 by Yendor 5/15/04 10:03:33 PM Reply	Nope. I'm not comprehension-impaired, either. For I also happen to know that Javascript != Java, and that the Javascript engine is built into the browser, whereas the JDK that runs Java applets is a separate program altogether. So you still haven't said WTF target="_blank" has to do with the JVM installed. -YendorMike [link\|http://www.hope-ride.org/\|http://www.hope-ride.org/]
Post #155,450 by Arkadiy 5/17/04 10:15:51 AM Reply	First, applets are not run in a separte program (process) For SUN JDK, they are loaded as an in-process ActiveX control, IOW, a DLL, into browser's address space. Second, the version of Java was the only different variable between Andread's setup and the original one. Not that it matters - it really should be irrelevant. But, who knows. I can see that applet's painting hanging, and, since all painting is done on one thread, leaving the window unpainted. Not a likely scenario, just barely possible. -- Buy high, sell sober.
Post #155,451 by ChrisR 5/17/04 10:25:45 AM Reply	IE behavior for JavaScript Having written a lot of intense JavaScript of late (with many accidental infinite loops), i find that IE has the most horrid multithreading imaginable. Once a thread takes control and winds up in a tight loop, you will completely lose control - no UI whatsoever. When this happens, the screen will lock, staying blank if nothing is there yet, or even showing ghost images from other windows that are maxmized and then minimized. Anyhow, yes this could easily be a JVM problem, or a JavaScript problem, or a browser problem. Hard to say since when the program gets hosed, the browser becomes inaccessible.
Post #155,452 by Steven A S 5/17/04 10:34:38 AM Reply	Re: IE behavior for JavaScript These laptops do use the new hyper threading Intel CPUs. Could this be contributing to the problem? ~~~)-Steven---- "I want you to remember that no bastard ever won a war by dying for his country. He won it by making the other poor dumb bastard die for his country..." General George S. Patton
Post #155,457 by Arkadiy 5/17/04 11:04:18 AM Reply	Once you get into that la-la land, all bets are off -- Buy high, sell sober.
Post #155,481 by ben_tilly 5/17/04 2:33:36 PM Reply	Yes If the problem is multi-threaded code getting into race conditions, then anything that increases concurrent work will make those race conditions more likely to be tripped. There should be a bios setting to have the CPU not use hyperthreading, making it present itself to the OS as a single CPU, not two. It is definitely worth giving that a shot. Cheers, Ben To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act - [link\|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20\|Nebraska Supreme Court]
Post #155,468 by pwhysall 5/17/04 12:29:44 PM Reply	Eh? WTF has that got to do with JavaScript? Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal] [link\|http://guildenstern.dyndns.org\|Blog]
Post #155,475 by Arkadiy 5/17/04 2:00:55 PM Reply	Applets have nothing to do with java script But, when you get wierd errors like failure to paint the window, all bets are off. I can't trace a path from different Java version to failure to paint windows, but if Java is somehow involved, I will not be too surprized. There is less connection between Java Script and display drivers, but nobody seems to be too surprized when display drivers are suspected. -- Buy high, sell sober.

Welcome to IWETHEY!