Link to home
Start Free TrialLog in
Avatar of rabbitzju
rabbitzju

asked on

How to hide the system tooltip

Dear:
  I want to hide the system tooltip. For example, when mouse moves to the right-top window close button of a dialog,the tooltip "close" appears.
  Then how to disable or hide the tooltip?
  Thanks in advance.

  rabittzju
   
ASKER CERTIFIED SOLUTION
Avatar of ShaunWilde
ShaunWilde

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of rabbitzju
rabbitzju

ASKER

Dear ShaunWilde:

  I'm working on Win98Se. My workmate is the same as yours.His platform is NT4. I don't know the reason.
Maybe the windows common dll is different or destroyed.
By the way , window2k is ok too.

rabbitzju

Dear peterchen:

  I had never created a titlebar. I will try .
  Later tell you the result.
  Thanks

rabbitzju
   
Dear peterchen:

  I had never created a titlebar. I will try .
  Later tell you the result.
  Thanks

rabbitzju
   
rabbitzju: again - my question, out of curiosity:

Why do you want to hide the tooltip?
Dear peterchen:
 
  If show tooltip, it will redraw the dialog and do sth.
In a word, it needs executive time. While our application
system is real-time.Without enough time, some data drop will happen.Avoiding it, one of  method is hide or mask it.
How do you think?
Thanks

rabbitzju

   
rabbitzju, please consider the following, although it is bad news:

Windows not Realtime

I've been involvewd with lengthy discussions about real-time applications under windows (here, and on CodeGuru). There are only two rock solid solutions:

a) A Kernel Mode device driver
b) a third-party "shell" (that is started before windows boots)

a) requires a half-a-guru at least (although documentation became better in the recent years); and for b) I saw an offer for this once; However, I can't find any link anymore.

There are some tricks you can do in user mode for "improving real-time-responsiveness" of windows, but they all have the same problem: they give no guarantees.

So you could stay in user mode, and do some "dirty tricks" (probably investing good amount of time), but you will still have data loss now and then.

THERE IS NO GUARANTEE when windows will execute your code (as long as it's not a kernel mode driver)

Peter
Dear Peter:

  Thanks for your attention @_@
  I know windows is not a real-time system. In fact, we only realize inaccurate real time. Datadrop is permitted.
But we should reduce it furthest.


rabbitzju 06/28
maybe you should think if receiving your data on a high priority thread and leaving the GUI to run in another lower priority thread
Dear ShaunWilde:

   We used thread early. As you know, thread is controlled
by window itself. Nobody know which thread will run at some
time slice.And I remember thread precision is ten millsecond or more. Our system sample frequecy is high.
Finally, we abandoned this scheme.

rabbitzju 06/28

rabbitzju: ShaunWilde is right when suggesting threads.
Everything i running in a thread, that has to live under the same scheduling rules as other threads. Step-by-step removing the "major causes" of interruption won't take you far, as there are too many to account for, on too many different systems.

To get "best performace" out of windows, you need to:

* create a worker thread that does the sampling
  this thread should have THREAD_PRIORITY_TIME_CRITICAL

* The worker thread MUST give up time slices (WaitForXXXObject, suspend, sleep, SwitchToThread) to allow other threads to run

* for your main thread, use SetThreadPriorityBoost(GetCurrentThread(), false). This disables the priority boost for your thread, when it receives user input

* Finally, you can use SetPriorityClass(GetCurrentProcess(), REAL_TIME_PRIORITY) note that this might be prohibited for the account your app runs under.

* DO ALL THIS ONLY FOR THE TIME INTERVAL WHERE YOU NEED THE HIGH PRIORITY
And this time should be short - as short as possible. Rule of thumb would be 500 ms if you do all of this.

* If you need only short intervals (<=10ms), you can even improve responsiveness by putting in a SwitchToThread() just before you need the high responsiveness. This gives other important threads a chance to run, so they are less likely to interrupt you ther next time you get scheduled.

Peter
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:

Answered by : ShaunWilde, peterchen (points to be split)

Please leave any comments here within the next seven days.

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

Roshan Davis
EE Cleanup Volunteer