|
I'm not exactly sure what you are asking.
offset 4h contents GUID of shortcut files is 24 bytes in length
offset 1Ch contents Time 1 is 8 bytes in length
offset 24h contents Time 2 is 8 bytes in length
offset 2Ch Contents Time 3 is presumably 8 bytes in length
A char is one byte. A short is 2 bytes. A long is 4 bytes. An int is the same size as the system word (4 bytes in 32-bit OSs).
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
LOL fine, what is a 64 bit int in C? Not platform specific?
|
|
|
|
|
KingKruncher wrote:
what is a 64 bit int in C?
long long, but not all compilers support it.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
A Microsoft-specific __int64 type exists.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_langref___int8.2c_.__int16.2c_.__int32.2c_.__int64.asp
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
I've an application written in MFC. The main window is a subclass of CFrameWnd. I'd like to have an option to set the window always-on-top, so I've got a check menu item "Always on top" on my "View" menu. The command handler for this (method OnAlwaysOnTop) checks the state of the menu item check, toggles it (this works fine) then calls this->ModifyStyleEx( 0, WS_EX_TOPMOST ) or this->ModifyStyleEx( WS_EX_TOPMOST, 0 ) depending on whether it is setting or clearing the state respectively. For some reason I always get a zero return from ModifyStyleEx() meaning it has failed (non-zero means success) and the window does not go topmost.
- Can a CFrameWnd (or a derived class) have the WS_EX_TOPMOST extended style set?
- Does the WS_EX_TOPMOST extended style actually mean always-on-top or does it simply bring to front until another window is activated?
- The window is created using Create(), in order to use extended styles must I use CreateEx()?
In the debugger this is definetly the correct derived class.
Any tips on how I can achieve this feature?
Thanks all in advance. Please ask if I have been unclear on anything or you need more information.
Cheers,
Robin
|
|
|
|
|
Look at SetWindowPos()
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
Works a charm, I used:
SetWindowPos( &wndTopMost, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE );
Thanks a lot 
|
|
|
|
|
I know what you will say: There are some sources on this site....
all I find was in MFC,
Here is my probleme:
if I do this:
case WM_INITDIALOG:
{
DragAcceptFiles(hwnd,TRUE);
........
...
}
no problemo, I catch the WM_DROPFILES
but I want it for my list view control (IDC_LIST1)
so I did that
case WM_INITDIALOG:
{
DragAcceptFiles(GetDlgItem(hwnd,IDC_LIST1),TRUE);
........
...
}
and impossible to catch the msg...
I try to catch everywhere, whitout result..
if someone can help me!!!
|
|
|
|
|
youpiyoyo wrote:
I try to catch everywhere
Did you try subclassing the list control?
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
How do I subclass the list control????
|
|
|
|
|
Type CListCtrl in the Search window and click the Go button
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
As I had said before in the title, it was coded in api win32, and not in MFC,
so for the CListCtrl it won't work.....
I try something with windowlong...
|
|
|
|
|
MFC does not change the way a control works. All the same styles, messages and structures apply equally.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
ok thank you for your help, I finally found it, you tell me the truth, with subclassing...
for people who are interesting there is my solution:
<br />
WNDPROC wpOrigEditProc;<br />
<br />
LRESULT APIENTRY EditSubclassProc(<br />
HWND hwnd, <br />
UINT uMsg, <br />
WPARAM wParam, <br />
LPARAM lParam) <br />
{ <br />
if (uMsg == WM_GETDLGCODE) <br />
return DLGC_WANTALLKEYS; <br />
if(uMsg == WM_DROPFILES) MessageBox(0,"drop",0,0);<br />
<br />
return CallWindowProc(wpOrigEditProc, hwnd, uMsg, <br />
wParam, lParam); <br />
} <br />
<br />
LRESULT CALLBACK DlgMainProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)<br />
{<br />
switch(msg)<br />
{<br />
case WM_INITDIALOG:<br />
{<br />
DragAcceptFiles(GetDlgItem(hwnd,IDC_LIST1),TRUE);<br />
wpOrigEditProc = (WNDPROC)SetWindowLong(GetDlgItem(hwnd,IDC_LIST1),GWL_WNDPROC,(LONG) EditSubclassProc);<br />
<br />
........<br />
.......<br />
}<br />
...<br />
for people who have questions e-mail me!!!
|
|
|
|
|
I have a dialog with a picture box control on it. Within the picturebox I dynamically draw a CListCtrl object at a random position when the user clicks a button. Now I'm using a CRectTracker object to allow the user to resize and/or move the control. The problem is that when it gets the rect of the control, it gets it relative to the control itself, but when I call the control's MoveWindow function using those coordinates, it moves it relative to the parent window's coordinates, so that if I only move it over to the right one pixel, it moves it to the left coordinate of 1 for the parent window. I've tried using ScreenToClient, ClientToScreen, and I can't seem to get this to work right. Any help would be greatly appreciated.
Here's what I have so far in my control's OnLbuttonDown MessageHandler:
if (m_tracker)
{
m_tracker->Track(this, point, FALSE,(CWnd*)&m_pDlg->m_picWindow );
Invalidate(FALSE);
CDC* pDC = GetDC();
m_tracker->Draw(pDC);
LPRECT rect = new RECT;
CWnd* wnd = (CWnd*)this;
rect = LPRECT(m_tracker->m_rect);
LPRECT rect2 = new RECT;
LPRECT rect3 = new RECT;
m_pDlg->m_picWindow.GetWindowRect(rect3);
this->GetWindowRect(rect2);
wnd->MoveWindow(rect,TRUE) ;
delete rect;
rect = NULL;
}
CListCtrl::OnLButtonDown(nFlags, point);
If it's broken, I probably did it
bdiamond
|
|
|
|
|
bdiamond wrote:
rect = LPRECT(m_tracker->m_rect);
Where is m_rect being defined/assigned?
______________________________
dNimrod#X
________________________
|
|
|
|
|
the rect is set for CRectTracker in this code (that I got from an example on codeproject):
CListCtrl::OnSetFocus(pOldWnd);
CDC* pDC = GetDC();
if (m_tracker)
{
delete m_tracker;
m_tracker = NULL;
}
LPRECT rect = new RECT;
CWnd* wnd = (CWnd*)this;
wnd->GetWindowRect(rect);
ScreenToClient(rect);
m_tracker = new CRectTracker(rect,CRectTracker::dottedLine | CRectTracker::resizeOutside | CRectTracker::hatchedBorder );
m_tracker->Draw(pDC);
If it's broken, I probably did it
bdiamond
|
|
|
|
|
That's somewhat messy including memory leaks. MoveWindow takes coordinates in relation to the client area of the parent window.
bdiamond wrote:
Within the picturebox I dynamically draw a CListCtrl object at a random position
What is the parent window of the CListCtrl?
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
yes, I know it's somewhat messy, and I actually deleted some of the mess just to make it easier to read here, but I will clean that up after I can come up with a solution. The parent of the CListCtrl is the CStatic-derived picture window; I've also tried it with the dialog being the parent, and I know that you're right about it moving it according to the parent window's coordinates, but I can't seem to get it to move accordingly even using ClientToScreen or ScreenToClient ( I got confused, so I tried both).
If it's broken, I probably did it
bdiamond
|
|
|
|
|
bdiamond wrote:
at a random position
If the random postion is supposed to be within the Picturebox then there is no reason to use GetWindowRect() and ScreenToClient() into this. You only need to find a x,y coordinate that is zero based within the picturebox... so the limit is the width and height of the picturebox minus the width and height of the list control. Keep it simple.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
the code to place the control is fine and that is done in my class's constructor. The problem is that using the CRectTracker, the m_rect member is based upon the control's coordinates. If I move the control over to the left one unit, the m_rect will have -1 as it's Left member. so when I use MoveWindow, the control is placed at -1 in its parent instead of just moving over to the left one unit. m_rect is using the control's coordinates, and Movewindow is using the parent's coordinates.
If it's broken, I probably did it
bdiamond
|
|
|
|
|
bdiamond wrote:
If I move the control over to the left one unit,
Sorry but now you have lost me. That does not match what your original post said
bdiamond wrote:
I dynamically draw a CListCtrl object at a random position when the user clicks a button.
So if you are trying to move the window based on it's current position you need this:
1) GetWindowRect of the list control
2) Transform the screen coordinates to client coordinates of the picture control
3) Adjust the rect as per positioning requirements.
4) Move the list control using the resulting coordinates
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
got it now, thanks!!
If it's broken, I probably did it
bdiamond
|
|
|
|
|
Hello,
I have downloaded and installed the latest service pack (6) for developer studio, and it seems to me that files I had saved with my programs using CObject serialization (I know, I know, bad choice), now can't be opened with the new compiled code and crash the program.
Has anybody else experienced this? 
Have no fear of perfection - You will never reach it
|
|
|
|
|
It seems odd that Microsoft would break something as ubiquitous as serialization with a service back, but you never know. Have you tried debugging and stepping through your routines? Can you tie the crash to a particular line in your code (e.g., a certain piece of data being deserialized)?
Also, what happens if you serialize with the latest service pack (6) and then deserialize?
I guess it's possilbe you were doing something that may have been working by accident, or some undocumented feature, and SP6 ended up changing that for whatever reason and broke your code. I'm merely suggesting some possible ways of figuring out what's wrong.
I think VC++ comes with something called a document viewer that can actually view serialized data files - but I am not sure as I have never used or experimented with it.
"Fish and guests stink in three days." - Benjamin Franlkin
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
