|
Thanks, Ryan buddy!
You are a real expert!! 
George
|
|
|
|
|
Hi, all.
I'm now working with an Atl ActiveX control which displays various of shapes such as lines and circles.
GDI+ seems to be a good choice for drawing.
however,can GDI+ be used in ATL ?
I mean ,does anyone know where to put 'GdiplusStartup' and 'GdiplusShutdown'?
I've tried to put then in 'OnCreate' and 'OnDestroy' like this:
class ATL_NO_VTABLE Catlgdiptest :
public CComObjectRootEx<ccomsinglethreadmodel>,
...
{
...
public:
LRESULT OnCreate(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
// GdiPlus
GdiplusStartupInput gdiplusstartupinput;
GdiplusStartup (&m_gdiplustoken, &gdiplusstartupinput, NULL);
return 0;
}
LRESULT OnDestroy(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
// GdiPlus
GdiplusShutdown(m_gdiplustoken);
return 0;
}
HRESULT OnDraw(ATL_DRAWINFO& di)
{
RECT& rc = *(RECT*)di.prcBounds;
Rectangle(di.hdcDraw, rc.left, rc.top, rc.right, rc.bottom);
Graphics graphics(di.hdcDraw);
Pen pen(Color(255, 0, 0, 255));
graphics.DrawLine(&pen, rc.left, rc.top, rc.right, rc.bottom);
return S_OK;
}
...
};
But it doesn't work--the control draws nothing than a rectangle.
Is there any idea about it?
It's great to give any hint!
|
|
|
|
|
If we drug the toolbar of the main window and click any control on a toolbar,
normally focus is returned to main window after we release the mouse button
(at least is how Microsoft toolbars behave)
I am trying to implement a toolbar.
When to return focus to main window?
|
|
|
|
|
A simple way to answer your own question is, what bugs you the most when you use toolbars? I would prefer to have the focus returned to the main window as soon as a control on the toolbar has been used. That way I can continue working without that extra click required to move the focus to the working area. But then again, people have different preferences.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
WiB wrote:
This is programming forum.
Your answer is not a programmer's answer.
Your questions was "When to return focus to main window?"!!!
What kind of answer do you expect when you ask that question? On the other "How can I return the focus to the main window?" would have been a question that receives an answer with source code. Sorry, but with that kind of attitude you won't be getting any source code from me. I just wasted my time browsing through source code to find examples for you?! .
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Excuse me.
"...hasn't really been well accepted as far as the ratings tell us so far " - Nishant S
|
|
|
|
|
That's okay. No hard feelings. I get a bad temper sometimes.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
WiB wrote:
Your answer is not a programmer's answer.
Yes it is
Half of writing programs for people to use it to work out how they want a program to behave. This includes how toolbars work. Most people will want toolbars where the focus is returned to the main window as soon as the mouse button is released, as you said. You weren't very clear in what you wanted to know. It appears that you wanted to know the best time to return the focus to the window, so that is what the reply was. There was nothing wrong with the reply at all.
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"
|
|
|
|
|
WiB wrote:
Such answer could give any user that ever used floating toolbars
Of course it could. Your initial question sounded like you were wanting to do something different, which is why Toni answered as he did. You didn't ask which event to handle, so the answer wasn't given. You can't expect people to answer questions you don't ask.
WiB wrote:
I would like to know on which event I should return focus to main window?
WM_LBUTTONUP
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"
|
|
|
|
|
Thank you.
I couldn't understand why I couldn't catch this message.
It seems that for owned forms (as my floatimg toolbar) Windows set the mouse hook.
But I have got an idea.
Hope it will work.
"...hasn't really been well accepted as far as the ratings tell us so far " - Nishant S
|
|
|
|
|
Ryan, I took your previous advice (given a few days ago) on not to make things worse. Thank you.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Toni78 wrote:
I took your previous advice (given a few days ago) on not to make things worse. Thank you
You're welcome Glad to be of help
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"
|
|
|
|
|
I don't understand the process you describe, could you please specify?
When do you click on the control, after the drop? When the toolbar is floating? Is the control something like a combobox embedded on the toolbar?
WiB wrote:
I am trying to implement a toolbar.
Do you derivate a new class from CToolbar or directly from CWnd?
We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)
|
|
|
|
|
Ok.
Just to be sure on the words we use, let's define some:
When a toolbar is detached, we say it is "floating". When it is attached, we say it is "docked".
The behaviour of a toolbar when floating is different of when docked.
With the MFC, when a toolbar is floating, it is no more the direct descendant of the main window but the descendant of a new window, a docking frame. This new window is created when the toolbar is detached and is generally from the class CMiniFrameWnd. So, if you try to activate the parent, it might be not the good one.
IMHO, it should be the window receiving the command sent by the toolbar button which should set the focus to itself, and not the toolbar setting the focus to the window.
HTH,
We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)
|
|
|
|
|
The PostMessage method sends a message in an asynchronous way, and returns immediatly.
We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)
|
|
|
|
|
Another solution could be to store a pointer on the window which had previously the focus when the toolbar is activated, and then restore the focus to this window (if it still exists) after the processing of the command.
We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)
|
|
|
|
|
Consider the following background information:
a) I have a static library, say A.lib
b) I create a DLL, say D.dll, in which I write functions that require me to link the dll with A.lib
c) I ship my dll i.e. D.dll
Now comes my doubt:
Do I need to ship the static library (A.lib) also along with the DLL?
(I observed that when I use the dll in developing an application, the compiler gives me LNK2001 errors for all functions in the static library A.lib.
Of course, all LNK2001 errors disappear if I include A.lib in the application workspace. (But that's not the idea, I guess))
Any help will be greatly appreciated.
Richard
|
|
|
|
|
richiehere wrote:
Do I need to ship the static library (A.lib) also along with the DLL?
A.lib is required by the linker, so the users don't need it, and the application that you are distributing requires only the DLL file. Therefore, the answer is no, you don't need to ship the static library.
However, if you are distributing only your DLL (which is required by another programmer to develop his/her own code which places function calls to your DLL) then you need to distribute A.lib and A.h as well.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Thanks for the reply.
I was quite aware that while shipping the 'exe', I dont need to ship the lib file.
My specific query was regarding shipping of the static library while shipping the dll.
I thought the linker (while creating the dll) would automatically extract out the 'code' from the static library and insert it into the dll code. Therefore, not requiring the lib to be shipped alongwith the dll!
Please help.
|
|
|
|
|
Don't get upset richiehere.
In the previous post I mentioned the fact that if ship your dll only, then you need to send your lib and header file as well. Yes, the linker inserts the code into the dll but the dll is used by the application. For a developer it is necessary to know the functions and the parameters to these functions. That's why the header file needs to be shipped. On the other hand, the linker needs to know where to get the code (or resolve external dependencies) so that's why you need the lib file. But, you can also load the functions from a dll by calling LoadLibrary. In that case the lib file is not required. Having the lib file is more convinient. I don't understand why you won't ship your lib file, but it is up to you to decide what you want to do. If I had a choice I would prefer to get my hands on the lib file instead of calling LoadLibrary.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Okay, maybe this might help you a little bit more. I just got it from MSDN.
"Types of Dynamic Linking
There are two methods for calling a function in a DLL:
In load-time dynamic linking, a module makes explicit calls to exported DLL functions as if they were local functions. This requires you to link the module with the import library for the DLL that contains the functions. An import library supplies the system with the information needed to load the DLL and locate the exported DLL functions when the application is loaded.
In run-time dynamic linking, a module uses the LoadLibrary or LoadLibraryEx function to load the DLL at run time. After the DLL is loaded, the module calls the GetProcAddress function to get the addresses of the exported DLL functions. The module calls the exported DLL functions using the function pointers returned by GetProcAddress. This eliminates the need for an import library."
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
I think you've has got the wrong end of the stick, if I understand his problem correctly.
A.lib is a static library used BY B.dll, and is therefore now "built-in" to the
DLL. It is not the LIB file created as a consequence of creating the DLL.
So he does not need to distribute A.lib under any circumstance. Unless an end user wanted
to use the static library themselves, but that would be independent of any reliance on
B.DLL.
You are right that he would need to distribute B.LIB along with B.DLL if he wanted
an end user to link to the DLL, but that is (I believe) a different question.
Iain.
|
|
|
|
|
Iain Clarke wrote:
You are right that he would need to distribute B.LIB along with B.DLL if he wanted
an end user to link to the DLL, but that is (I believe) a different question.
I covered both cases since I wasn't very sure about his question.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
First of all, thanks for all the 'activity' being generated on this thread!
Well I agree with you Ian, that is exactly my understanding. (the understanding that A.lib **need not**be shipped when shipping B.dll.
But thats not the way it is working out currently. I have done exactly that.
I am conscious of the fact that the size of the dll (B.dll) swells when I statically link A.lib with it.
However, when using it in an application, the MSVC compiler generates LNK2001 errors (symbol not found) for all of the functions in the static library!!
(I guess you might be skeptic of some settings in my compiler; but trust me it is plain code!)
Thanks for help again. (Btw,please respond to this question)
|
|
|
|
|
richiehere wrote:
First of all, thanks for all the 'activity' being generated on this thread!
You're welcome. It beats real work (which I should be doing...) and is more satisfying
than answering the "please do all my (home)work for me" questions that have been
reappearing.
I'll make an assumption that you have two projects in your workspace. B.DLL subproject,
and C.EXE project that depends on the DLL.
I would *strongly* suspect you are exposing A.LIB to to C.EXE, so it ends up linking
to A.LIB too. Make sure that the exe does not include any of the headers associated
with A.LIB, even implicitly.
I'd bet you have a B.H file with the definitions from B.DLL that includes A.H. If B.H
exposes any functions / classes that are not fully implemented in B.DLL, than C.EXE
will need to link them from somewhere, or it will give errors...
Its hard to be more specific without actually seeing your projects, so I'm having to
be general here.
Iain.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
