I don't see a problem; you get the path of the desktop and list the files in it. If you want to list the files of a different folder then get the correct path for the folder in question. And don't use getwd (or getcwd) unless you are certain that you are rooted in the correct directory to start with. Use a different method to select the folder you wish to list.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
I'm encountering the following problem. I wolud very much appreciate your help.
Description of the problem
MFC Desktop Application
Icons are supposed to be displayed in a CListCtrl as a CImageList.
It usually works fine except when using RemoteDesktop with the OS Windows 2008 / 2003.
In these particular cases the icons are just displayed as a black square.
Connecting with VMware vSphere (alternative to RemoteDesktop) -> Icons are shown appropriately
Remotdesktop on Windows XP / 7 / 8 -> Icons are shown appropriately
// Setting the symbol for this dialog-field. This is done automatically
// if the mainwindow of the application is no dialog-field.
SetIcon(m_hIcon, TRUE); // using big symbol
SetIcon(m_hIcon, FALSE); // using small symbol
In the real application, the source is a database which saves the Bitmap as a string. That’s the reason for the complicated code during the loading. Loading the images as a resource is possible, but in this case no option.
Drivers of server and client are updated to latest version.
I added the project here https://www.hidrive.strato.com/lnk/gRuMg38R. Thanks for helping out
Please don't bother about GetBitmapAsText(); because it only exists in the demo project in order to replace the complex algorithm and database infrastructure in the real project and make the problem portable. The correct loading of picture data from DB can be assumed because the problem is not that the picture can't be seen at all but that it can only be seen in certain circumstances.
The demo project gives you the function GetBitmapAsText(); which constantly and reliably delivers the same picture because it always returns a hardcoded string of base64-encoded picture data. Despite of this fact and despite of the constant algorithm for the presentation the presentation of the picture differs depending on the system. Therefore, for me the reason for the problem is situated somewhere in the interaction of the presentation algorithm with the specific system.
The only bridge I could build for you in order to make the picture data more transparent, would be to get rid of the base64 encoding and hardcode the picture data directly into picInBytes (BYTE*) as it is consumed by the API function CreateBitmap. But would it really help?
The only reason for checking the picutre data once again would be for me the knowledge of a limitation saying that CreateBitmap needs the data on different systems in different forms...
Well, we have to distinguish between published knowledge, unpublished/internal one and achieved by experience one. Writing here we primarly hope to find the third kind... but the first two kinds are welcome, too, of course.