|
I kind of forgot what this actually was, it's using the (OLE I believe?), IPicture interface to load the file/type automatically
|
|
|
|
|
|
Use OleLoadPicturePath() to get an IPicture interface, then IPicture::Render() to draw it. You could also use the shell's IExtractImage interface to generate a thumbnail, but doing so takes about 30 lines of code.
--Mike--
"Big handwavy generalizations made from a position of deep ignorance is one of the biggest wastes of time on the net today.
-- Joel Spolsky
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
|
|
|
|
|
|
Either Michael's way, or using GDI+
Graphics g(hdc);
Image img(imageFileName);
g.DrawImage(x, y, &img);
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 am developping application like photoshop
and have problem with making the title bar of dialog
boxes blue(just like when you activate dialog box,
but this time I want to make 2 or 3 dialog boxes
activated status). Any comments could be helpfull
Thank you in advance.
Shinya
|
|
|
|
|
|
Hey all,
I had a post on here about a week ago about executing code from memory instead of a PE file.
So far this is what I've done.
have this as the test code compiled
############################################
#include <stdio.h>
int main(int argc, char* argv[])
{
printf("Hello World!\n");
getc(stdin);
return 0;
}
compiled that and stored it as RCDATA resource 130 in my new project
############################################
this is the code I'm trying to execute it with, without writing it back to a file in my MFC dialog app
HRSRC hrInfo = FindResource(AfxGetResourceHandle(), MAKEINTRESOURCE(130), RT_RCDATA);
HGLOBAL hbytes = LoadResource(AfxGetResourceHandle(), hrInfo);
int (*ptr)(int argc, char *str[]);
ptr = (int (__cdecl *)(int, char *[]))hbytes;
int j = 1; char *strs;
(*ptr)(j, &strs);
CODE DONE
######################################
MODIFIED:
I also tried reallocating it with a FIXED flag, and it also didn't work
############ TRIED THIS TOO
HRSRC hrInfo = FindResource(AfxGetResourceHandle(), MAKEINTRESOURCE(130), RT_RCDATA);
HGLOBAL hbytes = LoadResource(AfxGetResourceHandle(), hrInfo);
int size = (UINT)SizeofResource(AfxGetResourceHandle(), hrInfo);
HGLOBAL pexec = GlobalReAlloc(hbytes, size, GMEM_FIXED);
int (*ptr)(int argc, char* argv[]);
ptr = (int (__cdecl *)(int, char *[]))pexec;
int j = 1; char *strs;
(*ptr)(j, &strs);
################
OK, the function I cast it to matches that of the main of the test code. BUT, it gives me an access violation. WHY? HGLOBAL DATA is supposed to be executable from memory without any special function right?, Will this work with the HGLOBAL as is, or do I need to explicitly GlobalAlloc it?
I realize that this may be an advanced topic, and I urge some people to refrain from replying as that my last post got a couple of very ignorant responses. Thanks for your understanding.
|
|
|
|
|
The topic is advanced, and using that kind of trickery requires skills and most importantly reason. I am not even going to discuss what possible reason you have to write code like this. Lets concentrate on what you actually trying to do:
Beer26 wrote:
HGLOBAL pexec = GlobalReAlloc(hbytes, size, GMEM_FIXED);
I am not completely sure what you expect from the statement above. I assume you want to create a copy of the resource in memory (I do not think GMEM_FIXED is going to be honored in Win32) You might be better off allocating new block of memory, insteadof realloc-ing something that you did not alloc-ed.
Beer26 wrote:
ptr = (int (__cdecl *)(int, char *[]))pexec;
I read the line above as - you assume that recourse you loaded is actually executable code of the function with signature "int (*ptr)(int argc, char* argv[]);" (please confirm). Are you sure that it is a valid executable code?
Beer26 wrote:
int j = 1; char *strs;
(*ptr)(j, &strs);
the line above actually try to execute the loaded code. (please confirm). Please note also that strs is not initialized.
How did you compile it? How did you put into resource? How are calls "getc" or "printf" going to be resolved ?
|
|
|
|
|
a) there is no guarantee that you have EXECUTE right on a HGLOBAL, but this doesn#t matter on Wintel Boxes
b) You *are+ aware that EXE files come a) with a PE header, and b) with a relocation table? They are not just "sequences of code bytes"...
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
"a) there is no guarantee that you have EXECUTE right on a HGLOBAL, but this doesn#t matter on Wintel Boxes"
From MSDN
"Remarks
If the heap does not contain sufficient free space to satisfy the request, GlobalAlloc returns NULL. Because NULL is used to indicate an error, virtual address zero is never allocated. It is, therefore, easy to detect the use of a NULL pointer.
Memory allocated with this function is guaranteed to be aligned on an 8-byte boundary. All memory is created with execute access; no special function is required to execute dynamically generated code. "
"b) You *are+ aware that EXE files come a) with a PE header, and b) with a relocation table? They are not just "sequences of code bytes"..."
Yes, I am. What if i write a small bit of code in ASM and only generate the OPCODE? Then try it with that? Would that work? I'm assuming it's not going to work with all the PE junk linked and compiled with it?
|
|
|
|
|
Beer26 wrote:
All memory is created with execute access;
Oops, sorry, I missed that (it's late over here ;-O )
b) yes that should work (as long as you refrain from absolute jumps/calls (or adress them correctly, with regards to the allocated base address)
If it doesn't, try to follow the thing in the debugger (disassembly window)
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
__asm
{
jmp (start of your code);
return;
}
|
|
|
|
|
woah, you gotta be kidding me, I'm going to try this now. It kind of makes sense too!
|
|
|
|
|
I'm including a class that has an inline function called
GetOldNodeIndex defined in the header file for that class.
When I try to access it, say in the main() function, the compiler
spills out (seemingly unrelated) unresolved symbol errors....
Here's the class definition
<code>
#if !defined(AFX_SPRINGNODE_H__7DC1CC9F_C211_478F_B542_9B71B4A3C4EA__INCLUDED_)
#define AFX_SPRINGNODE_H__7DC1CC9F_C211_478F_B542_9B71B4A3C4EA__INCLUDED_
#include "CM3DVector2f.h"
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
class CSpringNode
{
public:
unsigned int m_uiEntryTracker;
unsigned int m_uiNodeIndex;
unsigned int m_uiValence;
double m_dEnergy;
CM3DVector2f m_M3DPosition;
CSpringNode(unsigned int Index, CM3DVector2f& rPosition);
virtual ~CSpringNode();
bool operator<(const CSpringNode& rNode) const
{
return (m_dEnergy < rNode.m_dEnergy);
};
protected:
CSpringNode(){};
private:
unsigned int m_uiPreSortIndex;
public:
unsigned int GetOldNodeIndex() { return (m_uiPreSortIndex); };
};
#endif // !defined(AFX_SPRINGNODE_H__7DC1CC9F_C211_478F_B542_9B71B4A3C4EA__INCLUDED_)
</code>
and the main function
<code>
#include "stdafx.h"
#include "SpringNode.h"
#include "CM3DVector2f.h"
int main(int argc, char* argv[])
{
CM3DVector2f Vector;
Vector.x = 5.5;
Vector.y = -4.6;
CSpringNode aNode(0, Vector);
cout << aNode.GetOldNodeIndex() << endl;
return 0;
}
</code>
and the errors:
Compiling...
TrustRegion.cpp
Linking...
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCD.lib(dbgdel.obj)
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __endthreadex
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __beginthreadex
Debug/TrustRegion.exe : fatal error LNK1120: 2 unresolved externals
Error executing link.exe.
TrustRegion.exe - 4 error(s), 0 warning(s)
I should mention that if I remove everything that relates to the
inline function all those errors go away and everything works fine....
Anyone know what's going on here???
|
|
|
|
|
So if you comment out the cout << aNode.GetOldNodeIndex() << endl; line, all is well with the linker?
|
|
|
|
|
|
Then the next obvious question is what happens if you make the function non-inline?
|
|
|
|
|
The same thing. However, if I remove:
<br />
cout << temp << endl;<br />
cout << aNode.GetOldNodeIndex() << endl;<br />
<br />
it's okay. 
|
|
|
|
|
Which implies that you cannot use any method of that class, inline or otherwise. Correct?
|
|
|
|
|
Hmmmmmmmmmmmmm.....I suppose....
|
|
|
|
|
This doesn't work either:
<code>
int main(int argc, char* argv[])
{
CM3DVector2f Vector;
Vector.x = 5.5;
Vector.y = -4.6;
CSpringNode aNode(0, Vector);
unsigned int temp = aNode.GetOldNodeIndex();
cout << temp << endl;
return 0;
}
</code>
|
|
|
|
|
Are you building your application in multithreaded mode? This might be required when you use streams.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
That's just it - I'm not using any threads at all - the app is as
simple as you see it before you. The CM3DVector2f.h file contains
our own vector implementation and has been used EXTENSIVELY in MANY
projects, so I know it's not that - only seems to be related to
the inline function I described...
This is just a simple console app to demonstrate the problem - it's
driving me nutz!
|
|
|
|
|
I know this talks about old versions of the compiler and MFC but I think the result is the same.
SYMPTOMS
When compiling an MFC application using the single-threaded run-time library, you receive the following two unresolved external error messages:
nafxcwd.lib(thrdcore.obj) : error LNK2001:
unresolved external symbol "__beginthreadex"
nafxcwd.lib(thrdcore.obj) : error LNK2001:
unresolved external symbol "__endthreadex"
CAUSE
Starting with version 3.0, all MFC classes are "thread safe" and require the multi-threaded run-time libraries to link successfully. Many people try to use the single-threaded run-time libraries because they assume these libraries are needed to enable the application to run in Win32s. This is not the case. MFC versions 3.0 and later will use a single thread, so as long as you are not creating additional threads in the application, the application will run under Win32s.
RESOLUTION
To avoid these unresolved external errors, do not set the Project Settings to Single-Threaded for an MFC version 3.0 or later application. This setting can be changed by doing the following:
On Visual C 2.x and 5.0:
Select the PROJECT menu (and continue Steps 2 through 5 below).
On Visual C 4.x:
Select the Build menu.
Select the SETTINGS... option.
Select the tab, C/C++.
Select CODE GENERATION on the Category list box.
Finally, make a selection other than SINGLE-THREADED on the Use Run Time Library list box.
STATUS
This behavior is by design.
John
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
