|
Agree. I want to hide Icon, created by Shell_NotifyIcon().
|
|
|
|
|
In other words, you want to know how to use Shell_NotifyIcon() .
http://www.codeproject.com/shell/StealthDialog.asp
http://www.codeproject.com/shell/ctrayiconposition.asp
http://www.codeproject.com/shell/YaTrayMin.asp
http://www.codeproject.com/shell/siv_trayicon.asp
http://www.codeproject.com/shell/trayicons.asp
http://www.codeproject.com/shell/mfcstartup.asp
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=Shell_NotifyIcon&btnG=Google+Search
...should get you started.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
No. I know how to use Shell_NotifyIcon().
I don't know how to use it with another's applications ( created by NOT ME )
|
|
|
|
|
So what are you wanting to do with it? Are you wanting to change the behavior of another application for which you do not have the source code?
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
I want to make something like WindowsXP hide icons.
|
|
|
|
|
Hi!
How can I change the CodePage programaticlly????
Regards
George
|
|
|
|
|
Does SetThreadLocale() or _setmbcp() help?
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
I tried to set the codepage using these commands, but it didn't help. I added the command to the constructor of my CWinApp class. I want to set the Arabic codepage!
Do you have any other idea?????
|
|
|
|
|
George Clarence wrote:
I tried to set the codepage using these commands, but it didn't help.
Did SetThreadLocale() return a non-zero value? Did _setmbcp() return zero?
After calling SetThreadLocale() and _setmbcp() , did you then call GetThreadLocale() and _getmbcp() to verify the new setting?
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Hi!
I think, the SetThreadLocale command is used only to set the Language of the ressources and not to set the codepage. Is this true?
|
|
|
|
|
George Clarence wrote:
Is this true?
No. It also sets the code page.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Can someone point me to an article that discusses 100% owner drawn edit controls? I have been rolling my own controls lately, but CEdit has been troublesome. Perhaps I'm just lazy with the search tool, but there doesn't seem to be much on this topic on CP.
Cheers.
|
|
|
|
|
Hi there,
I have a CPropertySheet derived class which contains two different size property pages. I can dynamically change the size of the other property page by pressing "More/Less" button and it seems to work OK. But when this page is in full size and I activate another property page (which is smaller), how can I force Sheet/Page to redraw all the controls again? I have also same problem when I change the property page from smaller page to bigger. I tried to use RedrawWindow() and Invalidate() but those seems not to work in this case. Doos anyone have any idea what should I do?
TIA,
-HS
|
|
|
|
|
i am learning windows programming using Visual Studio .NET and i am having a problem with ShellExecute.
i have written a small tabbed window that shows shortcuts using Qt 3.2 (from Trolltech). the program is simply a convenient way of showing a selection of shortcuts for me to click on.
when i get a click, i run:
ShellExecute(NULL, "open", pszShortcut, NULL, NULL, SW_SHOWNORMAL);
where pszShortcut is a NULL terminated char * holding the full file name of a shortcut.
when i use this program to run Visual Studio:
pszShortcut = "D:\Documents and Settings\colin.MICROTEST.CO.UK\Tab Launchpad\Applications\Visual Studio .NET 2003.lnk"
VS loads fine, but i cannot compile due to the error:
Project : warning PRJ0018 : The following environment variables were not found:
$(QTDIR)
qt-mt - up-to-date.
QTDIR is defined as a user variable in control panel -> system, and is simply the string "c:\qt\live". if i run Visual Studio from the start menu, or by running my shortcut via windows explorer everything works.
i have also tried:
char *pszTest = getenv("QTDIR");<br />
qDebug("about to run, qtdir = {%s}", pszTest ? pszTest : "NULL");<br />
ShellExecute(NULL, "open", pszShortcut, NULL, NULL, SW_SHOWNORMAL);<br />
and the QTDIR environment variable is correctly returned.
it is as if the ShellExecute call is stripping some of the environment variables
i am starting to feel very out of my depth, so any help would be greatly appreciated. i am getting the same problem at work (winXP pro, VS .NET 2003) and at home (winXP pro, VS .NET, the one before 2003) so it isn't a machine specific problem, and i haven't been able to find any hints in the help or via google.
|
|
|
|
|
Somewhere in your project settings you try to load the environment variable $(QTDIR) which isn't possible (as far as I know atleast). You can only use the predefined variables, ie:
$(ConfigurationName)
$(PlatformName)
....
$(WebDeployPath)
$(WebDeployRoot)
etc. One thing is for sure. It hasn't got the slightest connection with your code It's just the project settings that cause the problem.
|
|
|
|
|
ah, um... *starts to get concerned i am doing impossible things, again*
in my project settings i have:
C/C++ -> General -> Additional Include Directories = $(QTDIR)\include
to be honest i am not sure why, but this is how i was told to set up a windows project. i have found you do have to reboot after adding the user environment variable in order for visual studio to detect it.
are there any "oddities" with ShellExecute that i should know about? i have a separate problem with my program because if i execute a shortcut to my Dialup Network connection (on my home machine) it doesn't do anything
thanks for the reassurance about my code
|
|
|
|
|
Well if they tell you that's the way to set up the project, I guess they are correct. Perhaps you've made a mistake in declaring it as a user variable instead of system variable or vise versa? Also if you are going to change the install directory of QT anyway, why bother and not just put the full path as include directory
|
|
|
|
|
i had another look at this last night. i loaded VS 6 times via my program, and about half the time it worked, and the other half the time the environment variable was undefined
so, i have simply removed the references to QTDIR in the project settings and used the directory instead. i would like to know what the problem was, but i am not sure i want to give the time and effort it would take. i will focus on more interesting and productive things instead
|
|
|
|
|
I know exactly what you mean. One part of you wishes to figure out what causes the problem, but that other part tells you to move on and work as you are running out of time Somehow though I most of the times tend to do the problem solving anyway...
|
|
|
|
|
Hi,
I have a control with a listbox and an edit on it. The control can be resized and both controls get resized as well. I checked my program with boundschecker and it found a resource error in each of those controls. It calls ReleaseDC while there are still non-stock objects in it. Well I checked and rewrote my drawing code like 10 times and it still didn't go away. I -know- it's flawless. So I reproduced the control step by step and noticed the resource error wasn't there when I didn't have the listbox on my control. Huh? So step by step I traced the error to the point that I resize the listbox.
Every time I resize the listbox my DC gets corrupted. Well I looked at the class styles of the listbox, and indeed it has the CS_PARENTDC style, so it could be very well possible that the listbox is the cause of my problem. But, here's the catch. It's just a stock listbox. I didn't do anything with it, straight from the Win32 API Did anyone else notice this error by Microsoft or am I overlooking something and is it a mistake made by myself?
To reproduce:
- Make a window
- Add a listbox
- On resize, resize the listbox
- Make sure you call both GetDC() and ReleaseDC() in any paint event (doesn't even have to be a paint event I suppose) of the window (you don't have to actually draw something, it just matters to call ReleaseDC() so boundschecker jumps in)
- Run boundschecker and resize the window a bit, it will trigger the error eventually
I tracked it even further. The following messages generate the error:
WM_NCPAINT
WM_ERASEBKGND
So what I did to solve it is to subclass the listboxes and handle these messages. Then I do the following:
LRESULT OnNcPaint(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL&) throw()
{
HDC hDC = ListBox.GetWindowDC();
int nSaved = ::SaveDC(hDC);
ListBox.DefWindowProc(uMsg, wParam, lParam);
::RestoreDC(hDC, nSaved);
ListBox.ReleaseDC(hDC);
return 0;
}
It works, but I don't like it that I have to do this to solve a problem which shouldn't be solved by me at all and neither to solve it this way. So again, does anyone have the same problems I have and if so how did you solve it?
|
|
|
|
|
Does this cause problems other than boundschecker complaints ? (gdi resource leaks ?)
|
|
|
|
|
Well it's quite simple. Boundschecker tells me that there are non-stock objects inside the DC. This means that there are objects created, selected and not removed and destroyed. I can't verify if they ever get destroyed as boundschecker doesn't check the windows code (I assume atleast). So there might just be a chance that there is a resource leak indeed...
|
|
|
|
|
Can someone please clear my confusion about the major function calls related to WM_PAINT and the sequence in which they are called. I want to know when these functions:
OnUpdate
OnInitialUpdate
UpdateAllViews
OnDraw
InvalidateRect
are called - whether before or after WM_PAINT, and in what sequence.
I've read that InvalidatRect just adds the rectangle to the update region, but it seems to me that a call to it also causes the window to be repainted immediately, or in ther words, a WM_PAINT is passed. Is that true?
It would be great if someone can explain me the MFC drawing sequence and procedure in detail. U see, i have just begun with VC and my project is entirely graphics based (OpenGL). So its imperative that i get a good grasp on the drawing mechanism.
Despo for your replys.
Thanks.
|
|
|
|
|
The only virtual methods which are called by the MFC framework are those with OnXXX.
OnInitialUpdate is called after the view is attached to a document but before the view is initially displayed.
OnUpdate is called if you change the document data and call UpdateAllViews. So OnUpdate is called by UpdateAllViews. The default implemenation is also called by OnInitialUpdate and it invalidates the entire client area and so it will be repainted if the next WM_PAINT messages is received.
UpdateAllViews should be called if you changed the documents data and so the view of the document must be marked invalid so that it is repainted in the next WM_PAINT message! So it forces the views of the document to display the changed data.
As I said above UpdateAllViews calls OnUpdate of all views which are attached to this document (except the sender view).
Note: you can prevent that OnUpdate invalidates the whole client area, if you overwrite UpdateAllViews/OnUpdate and pass a hint object with the information which part of the view must be updated in order to refelect the document changes!
InvalidateRect adds the given rectangle to the windows update region. The update region will be repainted if the next WM_PAINT message is received. It is used by OnUpdate to invalidate the given region of the view.
OnDraw will be called by the MFC framework in order to display the document. So OnDraw is called if a WM_PAINT message has been received.
|
|
|
|
|
OnUpdate and OnInitialUpdate are called by the framework. OnInitialUpdate is called when the view is first created, and can be used to perform some initial setup before it then calls OnUpdate.
OnUpdate is called by the framework in response to a call to CDocument::UpdateAllViews. You normally call UpdateAllViews if you've modified something in the document. This allows multiple views of the same document to be updated (maybe you have a CAD drawing, with different view windows showing different viewpoints of the design). UpdateAllViews calls OnUpdate for all views attached to the document, apart from the one passed in the pSender parameter.
CWnd::InvalidateRect is a simple Windows wrapper function (wrapping ::InvalidateRect) which tells Windows that a certain area of the window needs to be redrawn. When your thread's message queue is empty (apart from timer messages, which are the lowest priority), Windows posts a WM_PAINT message for each window that has an invalid region. MFC handles this in CView::OnPaint by retrieving the window's DC, calling OnPrepareDC to allow it to be set up correctly, then calling OnDraw().
OnPrepareDC doesn't do anything in CView's implementation; CScrollView overrides it to set up the scroll extents correctly. This allows you to use a single co-ordinate system whatever the current position of the scroll bars.
OnDraw() is also called when you use MFC's built-in printing support. This enables you to support both drawing to the screen and to a printer using the same code.
Most of the functions you're discussing are implemented in VIEWCORE.CPP. If you haven't installed the MFC source code, you may find it helpful to do so. The book MFC Internals by George Shepherd and Scot Wingo is still a good reference, despite being 8 years old; the core of MFC has barely changed since version 4.0.
|
|
|
|