|
What Windows Explorer stores in the lParam of TVITEM structure
If you retrieve information about treenode you have to use TVITEM structure. lParam of this structure allows to you to cache some data. Do you know what Windows Explorer caching here?
Thanks.
|
|
|
|
|
There is a good reason it is undocumented, to stop people from playing about too much.
That said, the ListView control has the PIDL stored in the items LPARAM. So, chances
are that will be the same for the Tree.
See here[^].
It is also possible that the LParam simply points to some internal structures holding pidls, and all sorts of com objects.
Iain.
|
|
|
|
|
How do you get your program to have XP-style buttons when running on XP? My buttons are still regular style. 
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
Quick Answer.
To get all the nifty new autotheme stuff, you need to have a manifest file.
Though I'm not the right person to ask more detail! I treat XP as W2K+Pretty.
OK, that was vague, but I hope it gives you a head start.
Iain.
|
|
|
|
|
|
Hi Guys,
In my Application i have some Menus. The Menus work fine with W2k and Win XP. The Menus look like those from MS Word (File -> New, File -> Open, File -> Save, File -> Save as etc.). On Windwows NT 4 they are displayed a bit strange.
File -> ,÷| (should be File -> New)
File -> ,÷| (should be File -> Open) and so on. I have this problem for the whole menus on Win NT 4 
Can anybody help me to solve this problem?
P-Rex
|
|
|
|
|
I had exactly the same problem a few years ago. I investigated, and found that MENUITEMINFO had expanded
post NT4. Fortunately, I didn't need any of the new fields, so I just used my own retro class. Newer
OSs can cope with the older structure, but not vice versa. You can get similar effects by playing with
platform definitions, but this seemed less intrusive. It is also better than MENUITEMINFO, as it self
initialises with sensible starting values.
struct CMenuItemInfo
{
UINT cbSize;
UINT fMask;
UINT fType;
UINT fState;
UINT wID;
HMENU hSubMenu;
HBITMAP hbmpChecked;
HBITMAP hbmpUnchecked;
DWORD dwItemData;
LPTSTR dwTypeData;
UINT cch;
CMenuItemInfo()
{
memset(this, 0, sizeof(CMenuItemInfo));
cbSize = sizeof(CMenuItemInfo);
};
inline operator LPMENUITEMINFO() const
{
return (LPMENUITEMINFO)this;
}
};
I hope this helps.
Iain.
|
|
|
|
|
Hello,
i have a problem with creating a completely owner drawn popup menu, because i cannot manipulate the border of it. Painting the menu-items in the way i want works fine. But the common 3d border will be drawn under Win2k always.
I searched in all menu-articles and in the message board. Also i did a google- and msdn-search. I don't know how to paint my own menu-border at all  ?!
Please help!
|
|
|
|
|
I would strongly recommend a look at Bruno Podetti's NewMenu article classes. It is well written,
had a *lot* of work in it (including a smidgeon by me), and I've used it to great effect in my
own projects.
Owner Drawn Menu with Icons, Titles and Shading [^]
It has a choice of a variety of styles, including menu shadows, and all that.
Iain
|
|
|
|
|
Thank you very much  !!! I will check the article!
Best regards
Tabor25
|
|
|
|
|
Here's the problem:
I have a memory DC that I create and keep around for the duration of the app. The mapping mode for this DC is setup once, and then never again. However there are times during the life of the app that I need to work in the default mapping mode (MM_TEXT). Instead of saving the context of the DC, setting up the default mapping mode and then restoring the DC to it's previous state, I thought it would be great if I could have two DC's that refer to the same 'surface' but that have different mapping modes. I know this is possible with a DC that references an actual output device such as the screen, but seems to be impossible with a memory DC. A second option I thought of would be to create a bitmap and select it into both DC's, then all drawing operations on any of the two DC's would go to the same bitmap/surface. Alas, the docs say a bitmap can only be selected into a single mem DC at any one time.
A third option I am considering, but haven't tried yet, nor do I know if it will work, is to create two DIB sections, one for each DC, with a common file mapping object and select the two bitmaps into their DC's respectively.
Any ideas on solving this problem would be greatly appreciated.
|
|
|
|
|
I developed a simple program.in that when i add an entry it stores data in the .dat file format.the file stores data perfectly in the vc++ environment.but when i link the exe file by the installer program to the start menu the .dat file not stores data properly.sometimes stores junk data,sometimes overwrite data etc.So i am having a problem in storing of data when i run the program outside vc++ environment.
|
|
|
|
|
may be some unexception problem,can you write your code for file handlling here,so other good programer can review it.
-----------------------------
"I Think It Will Help"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
Can you compile the program in debug mode and add ASSERT() statements? You might also want to add try/catch blocks to see if any exceptions are being thrown.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Hi CPians,
I have a problem with the following : I have a menu with two items, the second one being ID_OPEN_NORMAL.
I basically would like to change the item string it at runtime, which I do as follows:
CPoint point;
::GetCursorPos(&point);
CMenu menu;
DWORD dwSelectionMade;
VERIFY(menu.LoadMenu(IDR_MENU1) );
CMenu *pmenuPopup = menu.GetSubMenu(0);
ASSERT(pmenuPopup != NULL);
CString menustring;
CString str="Hello World";
if (!str.IsEmpty())
{
menustring = "Open "+str;
pmenuPopup->ModifyMenu(ID_OPEN_NORMAL,MF_BYCOMMAND,MF_STRING,menustring);
}
else
{
pmenuPopup->RemoveMenu(ID_OPEN_NORMAL,MF_BYCOMMAND);
}
dwSelectionMade = pmenuPopup->TrackPopupMenu( (TPM_LEFTALIGN|TPM_LEFTBUTTON|
TPM_NONOTIFY|TPM_RETURNCMD),
point.x, point.y, this
);
pmenuPopup->DestroyMenu();
The menu appears and the modified item string shows "Open Hello" as expected. However, dwSelectionMade contains 0 (instead of ID_OPEN_NORMAL) when I select the "Open Hello" item (so I cannot track the user's choice correctly afterwards) as if the user did not select any menu item.
It works OK for the first item, which I do not change dynamically (e.g. dwSlectionMade does contain the ID of the selected item).
Can anyone point out what I am doing wrong ?
Thanks,
~RaGE();
|
|
|
|
|
While I'm on the forum asking questions, let me contribute...
TrackPopupMenu doesn't return the selection made, it only returns whether it was successfull or not. You actually get sent a message telling you what the user selected. This means you will have to install a command handler for that particular menu ID. which will put the following in your header file:
afx_msg void OnOpenNormal(void);
The following in your implementation file
BEGIN_MESSAGE_MAP(YourWindowClass, TheBaseWindowClass)
....
....
ON_COMMAND(ID_OPEN_NORMAL,OnOpenNormal)
...
END_MESSAGE_MAP()
And the handler code
void YourWindowClass::OnOpenNormal(void)<br />
{<br />
<br />
}
|
|
|
|
|
I would completely agree with this, but ... if I do not modify the string with ModifyMenu, surprisingly and on contrary to what is said in the MSDN, TrackPopupMenu does return the made selection ! That's also ratehr obscure to me ...
~RaGE();
|
|
|
|
|
Two things:
Firstly, you are right that TrackPopupMenu returns the menu ID you have picked, as
you are using thre TPM_NONOTIFY|TPM_RETURNCMD flags.
Secondly, you have the third parameter of ModifyMenu wrong. This is from MSDN:
CMenu::ModifyMenu
BOOL ModifyMenu( UINT nPosition, UINT nFlags, UINT nIDNewItem = 0, LPCTSTR lpszNewItem = NULL );
You should have
pmenuPopup->ModifyMenu(ID_OPEN_NORMAL,MF_BYCOMMAND | MF_STRING, ID_OPEN_NORMAL, menustring);
instead of your version.
As the docs say, this is a deprecated api function. You might want to look at Get/SetMenuItemInfo,
though be aware that MENUITEMINFO changed size after NT4. See a later forum post for more info.
Hopefully this helps!
Iain.
|
|
|
|
|
Thanks Iain,
I have found this meanwhile myself, but thanks for pointing this out. As you said, I blamed TrackPopupMenu for acting badly while my parameters in ModifyMenu were wrong.
Thanks a lot.
Btw, I like ModifyMenu because I find it very straight forward, whereas SetMenuItemInfo, though more complete, requires using a structure, aso ...
~RaGE();
|
|
|
|
|
The OnTimer() function , which is called after a timer is created by SetTimer (),is processed when there is no other message to be processed. I wanted to make a second by second update to my program but it fails as when the user clicks very fast or if many messages are sent by the user or the program.
How can make a second by second update (a timer that will always get exact count)or ; make the WM_TIMER message to have higher priority
Thanks 
|
|
|
|
|
leyusha wrote:
How can make a second by second update (a timer that will always get exact count)or ; make the WM_TIMER message to have higher priority
forget it. Windows is not a Real-Time Operating System, that means that the kernel will always have priority upon the user events. this way, for an event to be treated, it will have to wait for the end of the event that is currently in treatment, or it will have to wait that the kernel finishes its task...
if you want this, sorry but, change your OS...
TOXCCT >>> GEII power
|
|
|
|
|
leyusha wrote:
The OnTimer() function , which is called after a timer is created by SetTimer (),is processed when there is no other message to be processed. I wanted to make a second by second update to my program but it fails as when the user clicks very fast or if many messages are sent by the user or the program.
How can make a second by second update (a timer that will always get exact count)or ; make the WM_TIMER message to have higher priority
You didn't mention how exact the count needs to be, so I should mention that you aren't ever going to get milisecond accuracy. However, it's quite possible that you can display an update so that the user sees something new about every second.
Another issue it that paint messages have an even lower priority than timer messages. If your program has long periods in which no timer messages get through, then no paint messages will get through either. This can lead to things like message boxes not being displayed, leaving the user wondering why your program has stoped responding. Because of this, the best solution is probably just to make your message handling efficient enough that timer messages can get through in a reasonable amount of time.
That being said, you can effectively make higher priority timer messages by having a background thread wait on timer messages or a waitable timer object, and having the thread send a WM_COMMAND or a custom message that will have normal priority. If the background thread doesn't do anything else, you can safely raise the thread's priority to get a bit more accuracy.
Nathan Holt
|
|
|
|
|
Nathan Holt at CCEI wrote:
You didn't mention how exact the count needs to be
was i the only one to see that he wanted a timeout of one second ( 1 s ) ?
TOXCCT >>> GEII power
|
|
|
|
|
toxcct wrote:
was i the only one to see that he wanted a timeout of one second ( 1 s ) ?
Windows can usually syncronize things to within a second. Audio and video players wouldn't be possible if that wasn't the case. If the OP can accept updates a quarter of a second late, he can probably get what he wants. There are sometimes high load situations that can delay things further, but users can often just avoid running too many programs. It works with things like Windows Media Player.
Nathan Holt
|
|
|
|
|
As the other reply states, you can't boost the priority of WM_TIMER. It isn't a real message in the
message queue, but is synthesised by windows.
But you can be cunning...
You can override CWinApp::Run and change the message loop to time out once a second, which is lot of
work.
Or...
Create a thread which does nothing much beyond:
DWORD MyTickingThread (LPVOID lpParameter)
{
HWND hWndNotify = (HWND) lpParameter;
while (g_CarryOnTicking)
{
::Sleep (1000);
PostMessage (hWnd, g_TickMessage, 0, 0);
}
return 0;
}
Of course, this is a very primitive example, but hopefully you get the idea.
You may want a more sophisticated (CreateEvent, etc) method of signalling to / from
the thread, and so on.
This still won't be exactly on the second, as windows is not a RTOS, but it will be
better WM_TIMER.
Iain.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
