C / C++ / MFC

6-Nov-06 8:57

I am a long time VB and ASP developer, experienced in both 6.0 and .net. I have had considerable experience in designing COM dll's and .Net class libraries for use by other applications. I am now trying to modularize a complex Visual C++ application by building dll's that can be referenced by different calling applications. Because of the complexity of the code, the short turn aound time and the lack of .Net and COM experience by the other members of the team, this is being done by building a number of Win32 dll's that will then be "plugged into" the calling application.

Therefore, I am trying to implicitly link a dll to an executable project using Visual Studio .Net (2002) Visual C++ 7.0. According to Microsoft, the search path used by Windows with implicit linking is 1. the directory where the executable module for the current process is located, 2. the current Directory, 3. the Windows system directory, 4. the Windows directory, and 5. the directories listed in the Path environment variable.

The documentation for VS 2002 states the "show directories for Executable files" on the "VC++ Directories" property page, lists the directories that Visual Studio will search for executable files and that it corresponds to the PATH environment variable.

I used this property page to link successfully to the library files in the lib directory of the dll project and the header files in the include directory of that project. I used the same means to link to the dll files in the bin directory of that project and I keep getting the "This application has failed to start because yadadyada.dll was not found. Reinstalling the application may fix this problem." message. When I built this application on another machine with VS 2005, the project properties page under Configuration Properties\Debugging had an entry called "Evironment" whereby I could enter the relative path to the YadaYada\bin directory; (Set PATH="..\YadaYada\bin"). But I was not able to find any equivalent entry on the property pages in Visual Studio .Net (2002). I manually added the path to the dll to the machine's "PATH" environment variable but it made no difference. When I copied the dll to the project's folder however everything worked as designed.

In my opinion, it is not good practice to include dll's to third party applications directly in your project's directory, (although I know that .Net managed applications do that with referenced third party namespaces). I am also not comfortable with adding third party dll's directly to the system32 directory. I feel that the calling application should be able to refer to the dll in the third party application's own bin folder. I would appreciate some advice on how to make this happen in Visual C++ if possible.

Thank you in advance for your assistance.

E.R. Joell MCSD MCDBA

Mark Salsbery6-Nov-06 12:45

6-Nov-06 12:45

joeller wrote:
In my opinion, it is not good practice to include dll's to third party applications directly in your project's directory, (although I know that .Net managed applications do that with referenced third party namespaces). I am also not comfortable with adding third party dll's directly to the system32 directory. I feel that the calling application should be able to refer to the dll in the third party application's own bin folder. I would appreciate some advice on how to make this happen in Visual C++ if possible.

Welcome to DLL hell. Even Microsoft calls it that. Smile | :)

Adding the path to the PATH environment variable is the way to do it but I believe you'll need a
full path, not a relative path. It doesn't work the same way as the path settings in the
Visual Studio environment, where paths are put together based on your project paths.

joeller7-Nov-06 3:42

7-Nov-06 3:42

"Adding the path to the PATH environment variable is the way to do it but I believe you'll need a full path, not a relative path."

Quite right which is what I did. no joy.

Mark Salsbery7-Nov-06 5:27

7-Nov-06 5:27

Even after reboot (maybe even just re-logon)?

That's worked since before Windows Smile | :)

joeller7-Nov-06 8:08

7-Nov-06 8:08

yeah

Mark Salsbery7-Nov-06 8:17

7-Nov-06 8:17

You may have seen this already but if not, maybe it will help...
Dynamic-Link Library Search Order[^]

Michael Dunn6-Nov-06 16:14

Michael Dunn

6-Nov-06 16:14

The "directories for executable files" setting has nothing to do with the DLL search path. That dir list is where the IDE will look for executables that get run in your build rules.
You'll need to do one of three things
1. Change the app's code to load DLLs from the bin directory (this will mean changing from implicit loading to using LoadLibrary())
2. Put the DLLs in the same dir as the app.
3. Change the machine's PATH variable and add your bin directory (not reliable, as the user can always change the PATH himself)

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ

joeller7-Nov-06 4:21

7-Nov-06 4:21

From original Post:

"When I built this application on another machine with VS 2005, the project properties page under Configuration Properties\Debugging had an entry called "Evironment" whereby I could enter the relative path to the YadaYada\bin directory; (Set PATH="..\YadaYada\bin")."

I neglected to mentioned that when this was done, everything worked as designed.

"But I was not able to find any equivalent entry on the property pages in Visual Studio .Net (2002). I manually added the path to the dll to the machine's "PATH" environment variable but it made no difference. When I copied the dll to the project's folder however everything worked as designed."

That was the full path to the specified folder.

I tried your #2 and it works. That is what everyone is doing now and I would like to get away from that.

I tried your #3 (see above) and it did not work.

I tried #1 several weeks ago. I don't remember whether it worked or not. As I recall it required the entry of the path to the dll in the code. However I am trying to avoid that because that would necessitate each developer putting the dll project on their machine in the same location for the code to work. In this non-optimum development environment, each developer uses source safe to get latest version and installs the projects in whatever location they so desire. They then use the VC++ Directories property page to set the linkages to the other header and library files that are needed. They have been copying the dlls into the project directory. Since I am only a contractor for this one project I do not want to tell them to revise their way of doing business. So I was trying to find means by which they could access dlls without copying them into the project directory. Of course this is the .Net solution. (Where the dll's for each name space that is referenced in your project is copied to your bin directory.) I never liked that resolution for dll hell because it requires that any new version of a dll (stuff like bug fixes and service packs), now need to be copied to every application that uses it. For very general reusable code,that is used in many places, (like this is going to be,) that means quite a lot of copying and checking.

What about the possibility of using the command line additional options under Configuration\C/C++ folder s of the project property pages?

E.R. Joell MCSD MCDBA

Mark Salsbery7-Nov-06 6:47

7-Nov-06 6:47

joeller wrote:
...this is the .Net solution. (Where the dll's for each name space that is referenced in your project is copied to your bin directory.)

Really? I haven't seen that behavior. Where is this documented?

joeller7-Nov-06 9:11

7-Nov-06 9:11

That was two years ago, I no longer remember were we read it. We were creating an ASP.Net application and we noted that after each build there was a copy of all the dll's we were using in the project's bin directory. We checked in out, and found that this behavior was as designed. Supposedly it was to allieviate the issues of DLL Hell to which the first replier referred to, as the application would always have the the version dll with which that it was compiled to work. The other advantage was that it facilitated the use of XCopy to deploy your application without worrying whether the dll that was needed was registered on the machine to which you were deploying. (The customer liked it because he did not have to register third party dll's on his server.) I found it irritating because I had come from a VB 6.0 background where you only had to set binary compatibility then you could replace the dll without having to re-register it.

I ran a google check before answering this entry. But I was not able to locate the place I read it. Could have been a book. Could have been 4GuysFromRolla. Found an entry in MSDN about referencing assemblies. Found a forum entry from a guy that found out the same thing we did. (He asked the question then posted the answer himself when no one answered him.) I am sorry I can't give you a better answer.

E.R. Joell MCSD MCDBA

Mark Salsbery7-Nov-06 9:33

7-Nov-06 9:33

Cool thanks.

A proper entry in the PATH environment variable should work. It's really strange that it doesn't
work for you.

Mark

joeller7-Nov-06 10:24

7-Nov-06 10:24

http://www.deitel.com/books/NET/AddingReferences.pdf

Page 4

CListCtrl SetItemPosition

Michael Dunn7-Nov-06 15:16

Michael Dunn

7-Nov-06 15:16

The environment setting in the project options only affects the app when you run it from the IDE, and even then all it's doing is modifying the PATH variable. This won't have any effect when the app is run on other machines.

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ

skullfire6-Nov-06 8:23

skullfire

6-Nov-06 8:23

Hey all.
I need to set the position of my items (in icon view) on a CListCtrl to a specified coordinate. I downloaded a demo called Thumbnail (http://www.codeproject.com/listctrl/thumbnailview.asp) and it works great. It uses the function SetItemPosition right after the app inserts an item like so:

// get current item position
m_ListThumbnail.GetItemPosition(i, &pt);

// shift the thumbnail to desired position
pt.x = nGap + i*(THUMBNAIL_WIDTH + nGap);
m_ListThumbnail.SetItemPosition(i, pt);
i++;

Now, on my application, I have a CListCtrl, and whenever i use this function, it doesn't set the position! I even tried to set the position to {1, 1} but the listctrl insists on positioning my items on default position.
My CListCtrl has these properties:
AutoArrange = false
Alignment = Top
Tabstop = true
View = Icon
This properties, I checked with the Thumbnail demo, work. Why doesn't it work on my dialog? Is there some sort of project setting or dialog configuration i should use so I can use this function?
I've also tried using the following functions, without any result.

<code>
SendMessageA( (HWND) m_listPix.m_hWnd, (UINT) LVM_SETITEMPOSITION32, (WPARAM) i, (LPARAM)&pt);

<code>
ListView_SetItemPosition32(m_listPix.m_hWnd, i, pt.x, pt.y);

How to save captured screen as jpg/jpeg file?

edvintas6-Nov-06 8:02

edvintas

6-Nov-06 8:02

hello,
please don't say "use GDI, use GDI blah blah..." i didn't found nothing about how to do it directly(without saving bmp first)
is it possible to use Image::Save method? how to convert captured screen to IStream? D'Oh! | :doh:

thank you very much for help Rose | [Rose]

Mark Salsbery6-Nov-06 8:12

6-Nov-06 8:12

edvintas wrote:
is it possible to use Image::Save method?

The Image class is GDI+ right? Unless you are using the .NET framework.

Since you don't want to "use GDI blah blah..." then I'd have to answer "No".

edvintas6-Nov-06 9:03

edvintas

6-Nov-06 9:03

yes, that image class is GDI+, but you missunderstood me, i want use GDI+ i just didn't found useful example how to do it... Sniff | :^)

i just said taht because i found some posts about bmp >> jpg but the answer was: "Use GDI+"
and nothing more, so i didn't want such answer as i already tried to use it and not successful so i need a bit help Smile | :)

Mark Salsbery6-Nov-06 10:42

6-Nov-06 10:42

Something like this maybe...

#include <gdiplus.hᡊe9ac73-238b-46be-991d-0f050c37248d   ...
// get a screen DC
HDC hScreenDC = GetDC(NULL);

// Create a Bitmap object - dimensions of screen (assumed 1 monitor)
int ScreenSizeX = GetDeviceCaps(hScreenDC, HORZRES);
int ScreenSizeY = GetDeviceCaps(hScreenDC, VERTRES);
Bitmap bitmap(ScreenSizeX, ScreenSizeY, PixelFormat24bppRGB);

// Create a Graphics object associated with the Bitmap
Graphics graphics(&bitmap);

// Draw the screen pixels on the Graphics object
HDC hGraphicsDC = graphics.GetHDC();
BitBlt(hGraphicsDC, 0, 0, ScreenSizeX, ScreenSizeY, hScreenDC, 0, 0, SRCCOPY);
graphics.ReleaseHDC(hGraphicsDC);

// Save as JPEG (GetEncoderClsid() code is in GDI+ SDK - see Image::Save())
CLSID JPGClsid;
GetEncoderClsid(L"image/jpeg", &JPGClsid);
bitmap.Save(L"MyScreenSnapshot.jpg", &JPGClsid, NULL);