|
thank you sir
u hav helped me alot
nw i hav to do it by myself
any ways
thx agn
|
|
|
|
|
Hello,
i have a PropertySheet with PropertyPages. If there is no button in a page the "OK"-button of the sheet is the default button. Otherwise the first button in the page will automatically become the default button (none of the buttons in the page has the def-btn-style). My client want me to set always the "OK"-button of the sheet as default button. So i tried SetDefID(IDOK) in the OnInitDialog-handler of the page. But it had no effect.
Is there an easy way to prevent the default behavior of the sheet or must i overwrite the WndProc() of the sheet or page and catch the message where the first button in the page is set do default?
Best regards,
Tabor25
|
|
|
|
|
Well, SetDefID(IDOK) wasn't going to work, as the OK button isn't actually *on* the page - its off it.
Maybe GetParent ()->SetDefID(IDOK) ? Or try setting focus to the OK button?
Iain.
|
|
|
|
|
I included windows media player control successfully, but now I am getting problem with that. I am not able to play movie inside that. It does not resond to any of its functions like SetFileName, SetEnabled,Play. Its buttons doesnot activate. All of its buttons remain inactive.
|| Lust Causes Sorrow ||
|
|
|
|
|
hi...
I have a number of items in a Treectrl. I want to drop a file on a particular item in treectrl....
i was placed the TreeCtrl in a DIALOG,derived from Cdialog class.
Mainly,I have to use ONDrag enter(),Ondargover() events in Dialog class...
is it posible to do this....if yes
How to do this.....?
is any body knows reply me....
|
|
|
|
|
Do you want to drag your items of a leaf to other leaf on the current tree?
|
|
|
|
|
i want to drag a file from windows explorer to current tree and have to drop it on a selected items in current tree
|
|
|
|
|
You could use COleDropTarget, something like:
...
class CMyTreeCtrlDropTarget : public COleDropTarget
{
protected:
virtual DROPEFFECT OnDragOver(CWnd* pWnd, COleDataObject* pDataObject, DWORD dwKeyState, CPoint point);
virtual BOOL OnDrop(CWnd* pWnd, COleDataObject* pDataObject, DROPEFFECT dropEffect, CPoint point);
public:
};
DROPEFFECT CMyTreeCtrlDropTarget::OnDragOver(CWnd* pWnd, COleDataObject* pDataObject, DWORD dwKeyState, CPoint point)
{
if (pDataObject->IsDataAvailable(CF_HDROP, NULL))
{
<code>
return DROPEFFECT_COPY;
}
return DROPEFFECT_NONE;
}
BOOL CMyTreeCtrlDropTarget::OnDrop(CWnd* pWnd, COleDataObject* pDataObject, DROPEFFECT dropEffect, CPoint point)
{
if (pDataObject->IsDataAvailable(CF_HDROP, NULL))
{
STGMEDIUM StgMedium;
pDataObject->GetData(CF_HDROP, &StgMedium, NULL);
DROPFILES *pDropFiles = (DROPFILES *)::GlobalLock(StgMedium.hGlobal);
TCHAR *pFileNames = (TCHAR *)((BYTE *)pDropFiles + pDropFiles->pFiles);
<code>
::GlobalUnlock(StgMedium.hGlobal);
}
return FALSE;
}
...
CMyTreeCtrlDropTarget MyTreeCtrlDropTarget;
...
MyTreeCtrlDropTarget.Register(pTreeCtrl);
Note this is a simple example. I haven't implemented the hittesting in
CMyTreeCtrlDropTarget::OnDragOver(). You may also want to return DROPEFFECT_NONE if the drop
target point isn't apropriate.
Hope this helps,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
"Go that way, really fast. If something gets in your way, turn."
|
|
|
|
|
hai Mark...,
Thanks for your sequence reply,and spending time for me.
i have added the class CDragdropmgr with derived class as ColeDroptarget. and i ceated an object for this class .
I written OnDropFiles() Event and necssaery code also in Treectrl Class....
SO. now if i drop files, what ever the code i written its working fine...
upto this clear. ok
now only the problem is starting.....
my objective is(Expected result): tried to drop a file on particular item in treectrl.
(Actual result but if i enter the treectrl none of the item get selected ...... and while doin dragover on items also no changes in selection in treectrl.
using the object which created for the class COLedroptarget.... how to achieve the above jobs.........
Warm Regards,
Manivannan.D
|
|
|
|
|
Get rid of the WM_DROPFILES/OnDropFiles() stuff. That only lets you get the dropped filenames
in the entire window.
In my code example (in red) check out the commented line:
"// Use the passed point to hittest on the treeview control to select the appropriate item "
There you have the cursor position (a POINT struct) and a pointer to the window.
That should be all you need to hit-test on the tree and select/unselect items as the drag
cursor moves over the control. The COleDropTarget::OnDrop() override has the same info and is
called when the files are dropped.
Make sense?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
"Go that way, really fast. If something gets in your way, turn."
|
|
|
|
|
Hi all!
I've meet a problem about DrawText. I wrote some code like following:
CString str[7];<br />
CDC *pDC=this->GetDC();<br />
<br />
pDC->SetTextColor(RGB(255,0,0));<br />
pDC->SetBkMode(TRANSPARENT);<br />
CDC memdc;<br />
CRect rc;<br />
GetClientRect(&rc);<br />
memdc.CreateCompatibleDC(pDC);<br />
CBitmap bmp,*oldbmp;<br />
bmp.CreateCompatibleBitmap(pDC,rc.Width(),rc.Height());<br />
oldbmp=memdc.SelectObject(&bmp);<br />
CPen mpen,*moldPen;<br />
mpen.CreatePen(PS_SOLID,2,RGB(120,120,120));<br />
moldPen=memdc.SelectObject(&mpen);<br />
CFont mfnt,*moldfnt;<br />
mfnt.CreateFontW(20,20,0,0,0,FALSE,FALSE,FALSE,GB2312_CHARSET,OUT_TT_ONLY_PRECIS,<br />
CLIP_DEFAULT_PRECIS,DEFAULT_QUALITY,FF_DONTCARE|DEFAULT_PITCH,_T("SYSTEM"));<br />
moldfnt=memdc.SelectObject(&mfnt);<br />
m_nGroupLeft=200;<br />
m_nContTop=200;<br />
rc.left=m_nGroupLeft+30;<br />
rc.top=m_nContTop+20;
rc.right=m_nGroupLeft+200;<br />
rc.bottom=m_nContTop+50;<br />
ClientToScreen(&rc);<br />
memdc.SetTextColor(RGB(255,0,0));<br />
memdc.SetBkMode(TRANSPARENT);<br />
RECT rc_txt;<br />
rc_txt.left=rc.left;
rc_txt.top=rc.top;<br />
rc_txt.right=rc.right;
rc_txt.bottom=rc.bottom;
memdc.DrawText(_T("Test\0"),-1,&rc,DT_LEFT|DT_SINGLELINE);<br />
pDC->BitBlt(rc.top,rc.left,rc.Width(),rc.Height(),&memdc,rc.top,rc.left,SRCCOPY);
memdc.SelectObject(moldfnt);<br />
mfnt.DeleteObject();<br />
memdc.SelectObject(moldPen);<br />
mpen.DeleteObject();<br />
memdc.SelectObject(oldbmp);<br />
bmp.DeleteObject();<br />
memdc.DeleteDC();<br />
The thing I can't make clear is that the output of this code is only a half of 'Test'. When I assign the rc.top as m_nContTop + 10, the string is disappeared. I think the coordinates in the DrawText are the Text's position. But why the string will disappeared when I decrease the value of rc.top? And when the value increase, the string can appear? Thx!
Regard!
whiteclouds
|
|
|
|
|
I think the coordinates in the DrawText are the Text's position.
I could hardly get what you mean by saying 'Text's position'.. Anyway, DrawText works on the same coordinate system as other CDC functions do. Particularly, it works with logical coordinates set by the current mapping mode.
But why the string will disappeared when I decrease the value of rc.top?
Simply because by decreasing the rc.top, you are offseting the entire rectangle. You might think that 'decrease' would inflate the rectangle.. but not. Use CRect::InflateRect instead, or besides decreasing rc.top also increase rc.bottom.
--
=====
Arman
|
|
|
|
|
I am writing a dialog-based program having a richedit control.
But when i type a url to it,it auto display it with blue color,but I want to change it to show red color.
How should I do this?
Thanks.
GOOD LUCK
|
|
|
|
|
try the SetSelectionCharFormat() function.
|
|
|
|
|
but it could not work well.
would you like to give a demo?
Thanks.
GOOD LUCK
|
|
|
|
|
Hi fellows
I'm programming C++ approximately 1 1/2 year, and I programming for windows too. But some keywords I don't know exactly what they are and when I use them. That's my question:
What the meaning of terms and when I use them:
__stdcall
__pascal
__fastcall
__thiscall
inline
It seems that's beginner question but I would like some answer to this question
Thanks for help again
|
|
|
|
|
All these are calling conventions. Actually __thiscall is not a keyword last time I checked. The calling convention specifies the mechanics of calling a function at the machine code level: it dictates such things as whose responsibility it is to clean up the stack and how arguments are passed. If you want to know more details you’ll have to learn some machine code.
Steve
|
|
|
|
|
In addition to what's been said, know that in Windows, native DLL [edit] exported [/edit] functions have to be __stdcall.
This affects stuff like stack order, which registers are used, etc. But the reality of it is in practice, make sure you don't use one type in a library and define it as a different one in the header. You'll get plenty of linker errors that way.
Btw, inline is in a court all its own. Rather than calling a function, the compiler attempts to take the body of that function and insert it into the block it was called from, thus saving the overhead of calling the function. Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.
|
|
|
|
|
Jeremy Falcon wrote: Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.
This is not true for really small functions. For example if a function simply added two numbers or returned some value then the function call overhead will be bigger then the actual code and inlining will save time and space.
Steve
|
|
|
|
|
We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine.
Nevertheless, what you just described is really better served as a macro, considering the restrictions on inline functions and compiler issues associated with them.
|
|
|
|
|
Jeremy Falcon wrote: We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine.
Here's some code I used to measure:
#include "stdafx.h"
#include <iostream>
inline int Add(int l, int r)
{
return l+r;
}
void PrintResult(int r)
{
using namespace std;
cout << r << endl;
}
int main(int argc, char* argv[])
{
int res = Add(1, 2);
PrintResult(res);
return 0;
}
I compiled twice: once with the inline on the Add function and once without.
Here's the code with the inline :
18: int main(int argc, char* argv[])
19: {
004010F0 6A 03 push 3
004010F2 E8 89 FF FF FF call PrintResult (00401080)
004010F7 83 C4 04 add esp,4
20: int res = Add(1, 2);
21: PrintResult(res);
22:
23: return 0;
004010FA 33 C0 xor eax,eax
24: }
004010FC C3 ret
As you can see the Add call has been entirely optimised away to a push 3 !
Here's the code with the inline commented out:
7: int Add(int l, int r)
8: {
00401080 8B 44 24 08 mov eax,dword ptr [esp+8]
00401084 8B 4C 24 04 mov ecx,dword ptr [esp+4]
00401088 03 C1 add eax,ecx
9: return l+r;
10: }
0040108A C3 ret
18: int main(int argc, char* argv[])
19: {
00401100 6A 02 push 2
00401102 6A 01 push 1
00401104 E8 77 FF FF FF call Add (00401080)
20: int res = Add(1, 2);
21: PrintResult(res);
00401109 50 push eax
0040110A E8 81 FF FF FF call PrintResult (00401090)
0040110F 83 C4 0C add esp,0Ch
22:
23: return 0;
00401112 33 C0 xor eax,eax
24: }
00401114 C3 ret
We have an Add function and main is bigger! My statement is correct: using inline on small functions can and often does make the code smaller (and faster)! We saved 19 bytes of code by adding the inline !
Jeremy Falcon wrote: Nevertheless, what you just described is really better served as a macro, considering the restrictions on inline functions and compiler issues associated with them.
Macros make debugging harder and are not type safe. Never use a macro when an inline function can be used instead!
Steve
|
|
|
|
|
In your attempt to be pretentious you overlooked the fact I didn't deny your points on one-line routines. I suggest you actually read my posts this time around.
Also, it's true macros are not type safe inherently, but the contents of it are as it's just code. And, if you reread what I said (and this time actually read) macros do avoid the compiler issues AND usage restrictions associated with inline routines. And no, use Google if you're really interested on what those are.
Never use an inline function in place of a one-line macro, assuming you care about portable code - which you apparently do not.
|
|
|
|
|
I was not (and am not) attempting to be pretentious. I said that your original statement about inline functions making functions bigger was “not true for really small functions.”:
Jeremy Falcon wrote: Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.
Stephen Hewitt wrote: This is not true for really small functions. For example if a function simply added two numbers or returned some value then the function call overhead will be bigger then the actual code and inlining will save time and space.
To this you replied as follows:
Jeremy Falcon wrote: We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine.
I did read your posts and have done so again when preparing this reply. Your assertion that, “if you call an inline function a lot, you'll increase the size of your exe substantially”, is simply not true for small functions. In fact the opposite is true: if the inline function is small then the more you call it the more space you’ll save!
You’ve obviously interpreted my (correct) comments as a personal attack. This is not the case. The CodeProject is about sharing knowledge and such. I can see nowhere in you post to justify your assertion that you, “didn't deny your points on one-line routines.”
Steve
|
|
|
|
|
Stephen Hewitt wrote: I said that your original statement about inline functions making functions bigger was “not true for really small functions.”:
You said that, and I said nothing to counter and yet you go on like I'm impressed or something.
Stephen Hewitt wrote: I did read your posts and have done so again when preparing this reply. You assertion that, “if you call an inline function a lot, you'll increase the size of your exe substantially”, is simply not true for small functions. In fact the opposite is true: if the inline function is small then the more you call it the more space you’ll save!
My point that the increase is relative to the size of the routine wasn't disproved. Yet you say it is, that's incorrect and for no other reason that I can surmise expect you're just looking to argue and/or just don't listen.
And yeah obviously, I wasn't talking about one-line routines at first, as I wouldn't do that, but I never denied your point on them. Which is why I find it odd you continue to press. I did say my statement was correct still however.
Stephen Hewitt wrote: You’ve obviously interpreted my (correct) comments as a personal attack.
I think you need to look up the word pretentious.
Stephen Hewitt wrote: I can see no where in you post to justify you assertion that you, “didn't deny your points on one-line routines.”
Really, well I don't see where I DID write one-line routines are bigger.
|
|
|
|
|
Stephen Hewitt wrote: Macros make debugging harder and are not type safe.
Also, if you need a debugger for a one-line routine, let's just say you're better off being a Wal-Mart cashier. Let's get real man, you know that realistically speaking a one line routine isn't that big of a deal to debug. Or dare I say, just copy and paste the contents of the macro into a block and run it if you must and then put the modified code back into the macro. The benefits outweigh having to use two extra keystrokes IMO.
|
|
|
|
|