C / C++ / MFC

Re: How I can Get DLL Version Number from resource file

26-Apr-06 7:44

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

jinzhecheng28-Apr-06 14:11

jinzhecheng

28-Apr-06 14:11

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!~

3D graphics

Gagnon Claude26-Apr-06 7:24

Gagnon Claude

26-Apr-06 7:24

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

Best way to setup environment for modular development ?

Defenestration26-Apr-06 7:14

Defenestration

26-Apr-06 7:14

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.

Re: Best way to setup environment for modular development ?

Blake Miller26-Apr-06 7:25

Blake Miller

26-Apr-06 7:25

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

Re: Best way to setup environment for modular development ?

Rilhas29-Apr-06 15:06

Rilhas

29-Apr-06 15:06

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

Handling asynchronous I/O

logicaldna26-Apr-06 6:24

logicaldna

26-Apr-06 6:24

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.

CTreeCtrl selection problem

RoyceF26-Apr-06 5:57

RoyceF

26-Apr-06 5:57

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

Re: CTreeCtrl selection problem

includeh1026-Apr-06 6:16

includeh10

26-Apr-06 6:16

it should work:
check clicking position, if clicking on button then move focus back to previous selected item.

Re: CTreeCtrl selection problem

RoyceF26-Apr-06 7:15

RoyceF

26-Apr-06 7:15

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

Re: CTreeCtrl selection problem

RoyceF26-Apr-06 7:17

RoyceF

26-Apr-06 7:17

CFileDialog & GetOpenFileName

RobJones26-Apr-06 5:24

26-Apr-06 5:24

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);

/* I can use either GetOpenFileName or CFileDialog and both cause the exception.
	OPENFILENAME ofn;
	TCHAR pszFile[MAX_PATH*2];

	_tcscpy(pszFile, _T("") );
	memset(&ofn, 0, sizeof(ofn));

	ofn.lStructSize = sizeof(ofn);    // I think this is the problem because of the SDK
	ofn.hwndOwner	= GetSafeHwnd();
	ofn.lpstrFile	= pszFile;
	ofn.nMaxFile	= sizeof(pszFile);
	ofn.Flags		= OFN_FILEMUSTEXIST | OFN_HIDEREADONLY | OFN_NONETWORKBUTTON | OFN_FILEMUSTEXIST;
	ofn.lpstrFilter = _T("All Files (*.*)\0*.*\0Executables (*.exe;*.ocx;*.dll)\0*.exe;*.ocx;*.dll\0");
	ofn.lpstrTitle	= _T("Please select a file");

	if (GetOpenFileName( &ofn ))
	{
		// I don't have to do anything it will still crash.
	}
*/	
	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)
	{
		// I don't have to do anything it will still crash.
	}

	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!

David Crow26-Apr-06 6:06

26-Apr-06 6:06

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

RobJones26-Apr-06 6:18

26-Apr-06 6:18

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

RobJones26-Apr-06 6:42

26-Apr-06 6:42

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!

RobJones26-Apr-06 7:16

26-Apr-06 7:16

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!

RobJones26-Apr-06 7:58

26-Apr-06 7:58

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

David Crow27-Apr-06 2:45

27-Apr-06 2:45

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

David Crow27-Apr-06 9:41

27-Apr-06 9:41

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

RobJones27-Apr-06 9:50

27-Apr-06 9:50

Yeah I found that one the other day too... Didn't make any difference... Microsoft has a patch but you have to call their support line to request it. I'm going to have work call and get the patch I think they have a support contract.

Thanks again for helping!
Rob

Whoever said nothing's impossible never tried slamming a revolving door!

RobJones1-May-06 3:55