If you move your mouse continually the query may not fail. Do not stop moving
61–70 of 168 posts
Re: If you move your mouse continually the query may not fail. Do not stop moving
#62This is a 11 year old knowledge base article for a bug in a product (Excel 97) that saw the light in 1997, that is 17 years ago. Yes, the second workaround is kind of hilarious, but let's not draw too many far-fetching conclusions from it. I believe many of us have seen crazier bugs.
like bot detection on NT-based systems? Yes, lets not talk about that.
Re: If you move your mouse continually the query may not fail. Do not stop moving
#63I had this bug once about 10ish years ago when I was still a windows dev. Creating a 2nd window on a thread with a window already but then pumping it's main loop on a background thread can cause this. If you do that the loops get hooked to each other regardless of the thread pumping it. The child window has to wait until the parent window forwards the event for the second thread to pop it off. A mouse move will send…
The rule of thumb as I always heard it is that a window is "owned" by the thread that created it. You can send and post messages from a different thread, but do much else and you're asking for trouble. (And Send instead of Post is often problematic since it will block until the target thread processes it.) Draining the message queue from a thread that doesn't own it makes absolutely no sense to me ... Does that actua…
Re: If you move your mouse continually the query may not fail. Do not stop moving
#64Nothing new for Microsoft: There is a reason, they had to drop Office 95 and completely re-implemented it. I guess, the day will come, that the current implementation must be abandoned too. The trouble with today's computing is: Just to much complexity around (starting from the OS, and that is also valid for Linux, I must say!) and to few really good programmers that make things better (and not worse). I see also in…
It's all well and good to say "Just keep it simple!" It's another to implement that.
I built and maintain a fairly popular RubyMotion library. It's goal is pretty simple: DSL out the ViewController hierarchy management and make it manageable for the application developer.
Every bit of code I add to what is now a fairly mature and full featured system pains me. But every bit of code addresses some edge case that we didn't think of, but which is quite valid.
An OS (like Linux, Unix, Windows) has orders of magnitude more issues to deal with than I do. In order to keep the system simple for users, they often have to add complexity to their code.
Simple for users just isn't the same as simple under the hood.
Re: If you move your mouse continually the query may not fail. Do not stop moving
#65Oh, so this actually works? How wrong I was all those times I scoffed at people moving their mouse around while waiting for a program. On a related note : isn't it interesting how this meme (mostly a placebo) traveled to the majority of computer users in a pre-internet age?
Re: If you move your mouse continually the query may not fail. Do not stop moving
#66I clearly remember old times with Windows 98/ME, where if you keep moving mouse, long-running operations like directory coping would be faster, thanks to CPU power savings not kicking-in.
True, but back then there was no "CPU power saving" mode. The CPU was slow and it always run at full speed (power was cheap back then). In the Windows NT series (4, 2000, XP, etc.) the sheduler gives the forground application an higher priority. It runs a longer CPU time than all other applications. This was probably also similar with Win 3 and 9x series but probably with many hacks and glue code on top of DOS. Movin…
If I remember correctly, one of the first moves towards power-saving in the stock-OS was Win 95/98/ME (one of those) to start using the HLT instruction (stop processor up to next interrupt) in the main OS, was a busy loop until then.
Notebook manufacturers (I worked with machines from Toshiba and Compaq in the 90s...) provided DOS TSRs and windows applications and drivers to control the CPU speed and display brightness.
Re: If you move your mouse continually the query may not fail. Do not stop moving
#67>> This problem has been reported when querying an ORACLE 7.3 data source by using the following ODBC drivers. Sqo32_73.dll is manufactured by Oracle Corporation. Microsoft makes no warranty, implied or otherwise, regarding this product's performance or reliability. Maybe not the fault of Microsoft?
I'm always fascinated by how tightly bound various software is with UI code in Windows. It's the equivalent of random shell scripts having Xlib or Gnome dependencies just to show a progress meter. I guess if it's an event loop thing one could also alternate 'z' and 'x' as fast as possible :-)
Re: If you move your mouse continually the query may not fail. Do not stop moving
#68This is a 11 year old knowledge base article for a bug in a product (Excel 97) that saw the light in 1997, that is 17 years ago. Yes, the second workaround is kind of hilarious, but let's not draw too many far-fetching conclusions from it. I believe many of us have seen crazier bugs.
>I believe many of us have seen crazier bugs. Might be, but is it a good sign for computer industry as a whole?
Re: If you move your mouse continually the query may not fail. Do not stop moving
#69Earlier quoted context omitted.
Microsoft designed and built the OS and two of the three applications involved. And the third application was almost certainly built using Microsoft development tools according to Microsoft guidelines. How could this not be their fault?
When I acquire a mutex inside my callback, it deadlocks. Microsoft wrote the calling function and the mutex implementation! Stupid Microsoft! Never mind that my callback violated the caller's threading model and that mutices introduce deadlocks when used incorrectly... They should fix the bug! Edit: I guess what I was trying to say is that this part needs a huge "citation needed": > was almost certainly built ... acc…
You're right that this discussion is light on details, but there is one relevant detail from which reasonable conclusions can be drawn: there is a workaround that involves moving the mouse around continuously. I can't think of any plausible scenario that could produce that behavior that does not involve some blatantly horrible design decision by Microsoft (hence "their fault"). It's possible that such a scenario exists, but I can't think of one, and I have not seen any such plausible scenario proposed by anyone else. I also know that Microsoft products are chock-full of blatantly horrible design decisions. In particular, Windows tightly couples the graphical UI with the OS kernel in a way that other OSes do not. It seems to me exceedingly likely that whatever is causing this problem has something to do with that.