|
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.
|
|
|
|
|
No, you don't need to distribute A.lib.
The library is needed by the linker to work out how to implement the calls to functions inside the DLL. It is not needed to use D.dll, and therefore doesn't need to be distributed.
Hope this helps,
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"
|
|
|
|
|
This is what richiehere wrote:
"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."
Therefore, I told him that the library file is needed by the linker, but a developer can also use LoadLibrary (as you know, little bit more work is required).
// 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
|
|
|
|
|
Aaah yes, but was he shipping the library so that other developers could use it, or was it part of his application that he didn't want other people to use? 
He didn't state this in the question. The most common situation these days is to ship a proprietary DLL as part of an application, so this is what I answered . Your reply is perfectly valid though
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've posted a reply to Toni78 which you should read[^].
Iain.
|
|
|
|
|
I have a dialog that I am going to transfer data from. When I have all of the edit boxes up and I run - no problem.
When I add up to 10 member variables (double and int total equal 10) I have no problem.
When I go past that small number of member variables I get this error?
MYSOURCE caused an invalid page fault in<br />
module KERNEL32.DLL at 0167:bff766bc.<br />
Registers:<br />
EAX=00550028 CS=0167 EIP=bff766bc EFLGS=00210246<br />
EBX=00000001 SS=016f ESP=00550000 EBP=00550010<br />
ECX=00550110 DS=016f ESI=817df560 FS=328f<br />
EDX=0055045c ES=016f EDI=00550028 GS=0000<br />
Bytes at CS:EIP:<br />
e8 13 ad ff ff 8b 55 08 8f 82 b0 00 00 00 8b 4d <br />
Stack dump:<br />
002a0014 00000000 00550028 00000000 005500f8 bff76733 00550028 005500f8 00000004 00550194 ffffffff 00000000 00000000 00000000 00000000 00000000
Right now, when I am setting the member variable and doing nothing else I get this error. Pushing the button the main dialog causes this window in question to popup. Then closing this window makes a list ctrl fill up in the main window. When the error takes place it looks like the list ctrl is trying to load, but it gives me the erroe before any data is on the screen?
Any suggestions are welcome!
I wish I could type better ...
|
|
|
|
|
I am kind of confused, so here are a few questions:
Are you able to pinpoint the exact line in your source code that leads you this error? (that would really help)
When you say that you cannot have more than 10 member variables, do you mean that you can have more than 10 edit controls on your dialog box but you can assign variables to only 10 of them?
To me is sounds more like you are trying to access something that you haven't initialized yet. A common error, is trying to read or send data to a control of a window that hasn't been created yet.
And finally (even though this doesn't seem to be the problem in your case) if you have visual studio 6.0 installed, make sure you have SP5 installed 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
|
|
|
|
|
For some reason the wizard wasn't defining the type of variables? Anyway, I put them in by hand and it works now. Thanks
I wish I could type better ...
|
|
|
|
|
You don't have to thank me. I didn't really get to help 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
|
|
|
|
|
I think like Toni78 (e.g. example of source code, assign variables)
I think the edit boxes aren't the problem, because in the past i have programmed a dialog with more than 100 edit boxes ... and Win95, Win98, WinME can support a maximum of 16.364 window handles. Other operating systems (NT4, 2000, XP) can support more.
Regards Frank
|
|
|
|
|
how do i plot the values i accpet in the dialog box on the view.i want to plot a point at the coordinates that i accpet from the dialog box.
i donno VC++ so please help!
Every problem has a solution!
|
|
|
|
|
In your dialog create a Data Map to exchange data from your dialog to your dialog class (if you use the app wizard this is done automatically, otherwize you should implement the DoDataExchange() method).
after doing that, derive your view class from CView and override OnPaint(). In the OnPaint, use pDC->MoveTo() and pDC->LineT0() to move around and draw lines.
good luck!
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
