|
I have developed a set of classes spread across several header and source files. Now heres the thing, I want to be able to #include just a single header file and not have to add all the files to the project. Obviously, when the source files are not added to the project the linker complains. Is there a workaround? I know a lib file could be created but I don't really want to do that if I can help it.
|
|
|
|
|
the linker can get the compiled code from a .LIB, it can get it from .OBJs as part of the project, or it can get it from .OBJs compiled outside the project.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Can't you create a header file and include all of your spread out classes in that header, then just include that consolidated header into your project?
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
|
|
|
|
|
I have that same problem very often, since I always generate lib files, which sometimes come from various libs and sources from the start. So I frequently need to merge ".h" files together, in order to get a single ".lib"+".h" pair.
The solution is very simple. The DOS command "copy" can be used to copy multiple files together. The line "copy a.h+b.h+c.h d.h" will copy "a, "b", and "c" into "d". You can automate the copy process by typing it in the "Post-build step" (or post build event in VC8). If you do that, then everytime you build your project the files will be merged automatically.
That works fine if the files you are merging include only system files. If they include specific files then you must remove the inclusion statements. I created a program to do text replacements inside text files, so I add it to the post build step to replace #include " by //#include " (I use the " to diferentiate from #include <, which should not be removed). Putting the replace application in the path makes it easy to do this in all my projects.
Rilhas
|
|
|
|
|
I am writting a DLL, and want to provide a function so that Client can query
DLL version by calling this function.
As you already know, the version number is in the resource file,
I tries LoadString() API call, but failed. Can anyone give some advice??
There are many articles on how to query DLL version given an exe or dll file,
my POINT is , how can I do it inside the dll it self ???
Thanks alot!
|
|
|
|
|
|
jinzhecheng wrote: There are many articles on how to query DLL version given an exe or dll file,
my POINT is , how can I do it inside the dll it self ???
Are you saying that GetFileVersionInfo() cannot be used in a DLL where the DLL's name is used as the first argument?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
Thanks Dave,
I thought this string is same as other string in resource file
This is a special case, instead of load string, use getfileversioninfo().
\
Thank you again!~
|
|
|
|
|
Hello,
I want to know wich library do you utilize to make wire framed 3D grapics with Visual C++ .NET.
I know that we can choose OpenGL. I want to know if someone utilize HOOPS or HEIDI.
Thanks,
Claude
|
|
|
|
|
I want to setup VC++ (using 2005, but that doesn't really matter) so that it makes it easy to do modular development. By that, I mean I want to create generic modules like CString, CPath which I can then use in all my projects. One way to do it would be develop all classes as single header files. These could then be put in a single folder called "Modules", with the path to this folder added to the INCLUDE search path of VC++. Each project could then just #include the modules header in each source file that used it.
A slight difference would be to create classes as a .c and .h file, and then just add these to each project that needed the module. Again, each project could then just #include the modules header in each source file that used it.
Another way, would be to compile the modules into .lib files which would then placed in a "Modules" folder along with the corresponding header file, with the path to this folder added to the LIB and INCLUDE search paths of VC++. This method has the advantage that complex modules can be developed consisting of multiple source files, which then compile to a single .lib file with a corresponding single interface header file.
Maybe a combination of the above methods, each depending on the complexity of the module being developed, would be the best way to go.
I'd be interested in hearing other people's opinions on the best/most efficient way to set up the development environment (IDE, folder structure, etc.) for this kind of modular development, including advantages and disadvantages of certain methods.
|
|
|
|
|
I put the CPP and H files into a separate folder called 'Common' or 'Shared'.
I add the path to this folder to the resource and general includes tabs for each project using one of the shared files.
Now, the reason I don't make them into libs, is that there are different project settings galore these days - debug, release, debug multi-threaded, release-multithreaded, unicode, mbcs, straight ASCII, etc. and a scad of optimizations.
So, you would need MANY different potential LIBS to be used in different projects.
So, I just find it easier for each project to just include the 'source' for each module it needs.
The disadvantage is that if you use something like serialization and one executable module (writing) is out of synch with another (reading), for example, you could end up with some strange run-time issues. But then, serialization should be performed in a DLL which they both share, to avoid such an issue in the first place.
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
I've been using a modular structure for years, at home and at work, based on LIB+HPP pairs.
This has various advantages. The first is that many projects take about 4 to 5 minutes to compile in the source form, and about 15 seconds using libs. That on a P4@4.2GHz.
Another advantage is that a module may be composed of various strange and hard to setup items. For example, I have a module for speech recognition that relies on SCANSOFT and LOQUENDO libraries, and some of my own wrappings. To use this as source would be difficult, since SCANSOFT and LOQUENDO's software has to be installed in the machine that compiles the module. On the other hand, pre compiling it and using it as a lib does not need LOQUENDO and SCANSOT to be installed (my libs include all other extarnal libs automatically).
My modules always have 3 files: "module_x.hpp", "module_x.lib", and "module_x_release.lib". The "hpp" file does not include any other external files or classes. This is hidden in the HPP, since all my classes have hidden internal data. For example, the HPP for a module could be as follows:
module_recognition.hpp
class Rilhas_Recognize {
protected:
struct Rilhas_Recognize_Data_Struct* itsData;
public:
Rilhas_Recognize();
~Rilhas_Recognize();
char* DoSomething();
};
This HPP does not need any inclusions, since it compiles without the exact definition of Rilhas_Recognize_Data_Struct. The CPP (which originates the libs) will be something like:
module_recognition.cpp
#include <stdio.h>
#include "this_file.h"
#include "that_file.h"
#include "loquendo.h"
#include "scansoft.h"
typdef struct Rilhas_Recognize_Data_Struct {
Rilhas_Recognize* object;
Loquendo_Handle handle;
char buffer[1000];
Scansoft_Handler asr;
} Rilhas_Recognize_Data;
Rilhas_Recognize::Rilhas_Recognize() {
itsData=new Rilhas_Recognize_Data;
itsData->object=this;
sprintf(itsData->buffer, "Hello world!");
}
Rilhas_Recognize::~Rilhas_Recognize() {
delete itsData;
}
char* Rilhas_Recognize::DoSomething() {
sprintf(itsData->buffer, "Hello again world!");
return itsData->buffer;
}
As you can see, the CPP can include many specific files. All internal operation data is hidden to the HPP and the HPP user, which makes it easy to distribute it. I use VC6, but for VC8 the setup should be easy as well. I simply create a workspace, named Module_X in its own directory. Inside it I create a "Source" directory where I will store the HPP and the source files used to produce the LIB, and where the compiled libs will be copied to. I also create a "Tools" folder where I store everything else the module needs (like LOQUENDO and SCANSOT stuff).
Then I create a project named Module_X_Con inside Module_X. This is a console project which I use for development. It includes the sources, and a simple "main.cpp" (which I create in the "Tools" folder). During development the CON project is used for debugging everything.
Then I create a Module_X_Lib which will take all the sources (except the "main.cpp" in the CON project). Note that I include external lib files to the lib project. The linker will add any external libs to the lib you are generating, so the lib becomes self-contained. In the post build step I add a command to copy the LIBs to the Source directory. Sometimes I also add a console project named "Module_X_Lib_Tester" that includes the libs and confirms everything is ok. It can use the same "main.cpp" file as the CON project.
Some projects require me to build a DLL. For that I create a "Module_X_DLL" project, and in the post build step I copy the LIB and DLL to the source directory, with the names "module_x_dll.lib" and "module_x_dll.dll" respectively. The release version takes the the names "module_x_dll_release.lib" and "module_x_dll_release.dll" (the Link name must be fixed for the release configuration). I sometimes add a console project named "Module_X_DLL_Tester" which takes the DLL libs from the Source and tests the DLL with the same "main.cpp" as before. Typically I add a pre-link step to the DLL tester to copy the DLL's from the source to the local directory.
This setup is very practical. You should note that I don't have dependent projects Y access the Source directory to take the libs or dlls directory. This is important, since I may be making changes which do not compile yet, and in the middle of the process I need to change and compile project Y. Or I may make a new version which is backward incompatible with project Y. For these situations not to be a problem, each dependent project Y has it's own "Tools" directory to where I copy frozen snapshots of everything it will need (hpp, libs, or dlls).
This project Y is then self-suficient and self-contained, and can even be passed on to another person. I still compiles perfectly even if it is 10 years old and module X has gone through several revisions, or if X has become incompatible with Y. When I need or want to update the X module in project Y I just go to the module X directory and bring fresh copies of the HPP, LIB, or DLL files to the dependent project's Y "Tools" directory.
As a final note, the multithreaded/singlethreaded version variations are usually not a problem. I used mixed versions in any project. When setting up a new project you may have to go to the link tab and ignore standard libraries like "libc", "libcd", "libcmt", and "licmtd". This is not difficult, since the linker detects the variation colision and sugests which library should be removed. I just go to the link tab and remove it, it is a very safe operation.
In the end the directory named Module_X will contain everything needed to build and test module X, including LIB's and DLL's. In the source directory I always find the CPP (which I do not use outside module X) and the distributables "module_x.hpp", "module_x.lib", and "module_x_release.lib". Eventually, for DLL projects, I also find "module_x_dll.lib", "module_x_dll.dll", module_x_dll_release.dll" and "module_x_dll_release.lib".
I hope this helps. It is nice to know that someone else recognizes the importance of adequate setup for modularity and code reusability.
Rilhas
|
|
|
|
|
I'm using win32 API CreateIOCompletionPort() for asynchronous I/O transfer, when transfer gets completed i'm chacking it with help of GetQueuedCompletionStatus() this calls are working on Win 2k server but having problem on win 2003 server..
any alternative to achive this asynchronous transfer..
this is what I finally want to do:
Monitor a folder for activities (Create,delete files/folder etc)
when a new Directory is added i want to capture the whether the I/O transfer is complete or not..
I should get a signal when last file is copied/transfered
------------------------------
Its not the fall that kills you; it's the
sudden stop at the end.
|
|
|
|
|
Hi,
I have a problem with a CTreeCtrl in a FormView. When the view is initially shown and the user clicks a button to expand a branch of the tree, the item is expanded, but also the first item in the tree is selected. I don't want this behavior. Rather, I don't want an item to be selected until the user explicitly selects one by clicking it. How can I fix this?
Thanks,
Royce
|
|
|
|
|
it should work:
check clicking position, if clicking on button then move focus back to previous selected item.
|
|
|
|
|
This is when the control is first displayed, so there is no previous item. Anyway, it appears that by default the first item is selected when the first expansion happens. It happens after the expansion is handled because there is no selection during the handling of the TVN_ITEMEXPANDED message. At any rate, I fixed the problem by adding a root item without any text. That root item gets selected, but because it has no text, it doesn't appear selected.
Thanks for your help,
Royce
|
|
|
|
|
This is when the control is first displayed, so there is no previous item. Anyway, it appears that by default the first item is selected when the first expansion happens. It happens after the expansion is handled because there is no selection during the handling of the TVN_ITEMEXPANDED message. At any rate, I fixed the problem by adding a root item without any text. That root item gets selected, but because it has no text, it doesn't appear selected.
Thanks for your help,
Royce
|
|
|
|
|
Hello,
I am still stuck on something I posted a question about a couple of weeks ago (I thought I figured it out but that isn't the case). I am using VC++ 2003 .NET. I believe that I did install the Windows 2003 Server SDK but I am not sure how I can tell, I don't see it listed in add-remove programs nor under updates.
Anyway, I have tried to use both CFileDialog and GetOpenFileName and both cause a First-chance exception. The exception doesn't happen the first time the file dialog is displayed but it will always happen the 2nd time its displayed. The error is listed below. I have done tons of research on the net and it appears that a lot of other people are having the same problem but I havent seen any resolutions that actually work (most suggest its a problem caused by the Windows 2003 Server SDK).
Heres the error:
First-chance exception at 0x7ca51406 in SiteConsole.exe:
0xC0000005:
Access violation reading location 0x016d4980.
Debugging hasn't lead me anywhere...
Heres the code: it's pretty straight forward.
void CExcludeDlg::OnBnClickedBImport()
{
UpdateData(TRUE);
static char BASED_CODE szFilter[] = _T("Text File (*.txt)|*.txt||");
CFileDialog m_ldFile(TRUE, _T(".txt"), NULL, OFN_HIDEREADONLY, szFilter);
if (m_ldFile.DoModal() == IDOK)
{
}
UpdateData(FALSE);
}
On a side note how can I uninstall windows 2003 server SDK? This may fix the problem.
Thanks!
Rob
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
Does this happen on all machines or just one in particular? Does it happen if you statically link with the MFC libraries?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
This is an administration application and we only run it on 2 workstations both are Windows XP and it's failing on both.
In debug mode I see the exception but in release mode it just closes the application with out any errors.
My application is currently statically linked with MFC.
I did just find this on the MSDN forums http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=154126&SiteID=1
They claim this problem was fixed with version 7.1 but I am running v7.1.3088 and I still have the issue... I went into afxdlgs.h and OPENFILENAME is currently defined as __declspec(property(get=GetOFN)) OPENFILENAME m_ofn;
Strange.
[Had to edit the URL]
Whoever said nothing's impossible never tried slamming a revolving door!
-- modified at 12:30 Wednesday 26th April, 2006
|
|
|
|
|
I just found out Microsoft release a 2nd revision of the SDK that is causing a lot of issues. I am going to try that now... Man I hope they fixed this.
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
The R2 SDK didn't help.. I have narrowed this down though... It only crashes when I mouse over a file name it crashes right before it displays the tooltip... Very weird...
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
Finally I found out what is causing the issue!! Now to try to figure out a work around...
After tons of searching on the net people were saying there is a shell bug with Adobe Reader 7.0 and to uninstall it to see if the bug goes away and IT DID!
Now is there a way to force the application to not load the acrobat dll? In the debugger I would see the CFileDialog load pdfshell.dll and then unload, on the second load if I do a mouse over to display the tool tip it would crash my app.
Whoever said nothing's impossible never tried slamming a revolving door!
-- modified at 14:34 Wednesday 26th April, 2006
|
|
|
|
|
By chance have you posted your question to the microsoft.public.vc.mfc newsgroup?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
See if this helps.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
