|
Where can I download GDI+ librarys and headers?
|
|
|
|
|
You can get it from:
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
I think it's in the core SDK part.
|
|
|
|
|
I've got a char array
<br />
char *vec;<br />
and i allocate memory for a number of elemets
<br />
vec = (char*) malloc ((sizeof(char))*(number_of_elemets));<br />
i do that in main.
then i call a free function
<br />
free_mem (vec);<br />
the function code is:
<br />
void free_mem (char *vec,number_of _elements)<br />
{ <br />
for (i=0;i<(number_of _elements);i++)<br />
{<br />
free (vec[i]);<br />
}<br />
}<br />
it gives me errors
what's wrong?
thanks!!
|
|
|
|
|
try this:
char *vec;
vec = new char[number_of_elements];
|
|
|
|
|
it's only ansi c, i can't use c++
|
|
|
|
|
I think you can just use free(vec), not free(vec[i]). Or maybe the error occurs because you forgot to pass the number_of_elements argument when you call free_mem?
|
|
|
|
|
Indrawati wrote:
I think you can just use free(vec)...
Correct.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Hello,
I compiled a program that reads the MAC-Adapter information and
therefore requires IPHLPAPI.DLL.
Now, on XPPro it's fine. DependencyWalker shows EFSADU.DLL to be
present in C:\windows\sytem32.
On XPHome, DependencyWalker shows this file as missing.
However, the program also runs on XP Home without any problems.
Now my question: Should I not care about the DependencyWalker warning
on XPHome? But then, why does this warning come up?
Could it be that DependencyWalker lists DLLs as missing although in reality they are never called (and therefore my app also works on XPHome)?
This is the dependency of the mentioned EFSADU.DLL:
IPHLPAP.DLL->MPRAPI.DLL->SETUPAPI.DLL->SHELL32.DLL->EFSADU.DLL
Thanks in advance for any help,
Tony
|
|
|
|
|
The Depends utility does not show DLLs that are explicitly linked. It only shows those that are implicitly linked.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
David,
thanks a lot for that information.
Do you know any way (or tool) that shows only explicitly linked
DLLs?
Thank you,
Tony
|
|
|
|
|
|
Thank you very much.
I used Process Explorer and it clearly shows that my app uses
iphlpapi.dll but does NOT use EFSADU.DLL which was listed by
DependencyWalker as not present on XP Home.
I must say that I have never heard about implicitly and explicitly
linked DLLs but assume it means that some DLLs are never used although they might be imported in header files (those would be the implicit ones).
So I think, to know which DLLs I have to include when I want to
distribute my app, I have to do the following:
1) Run the app.
2) Use Process Explorer to see which DLLs it really uses.
I guess I would have to do this in different usage scenarios.
I have no clue how DLLs are loaded into memory, but could it
be the case, that some DLLs are loaded only after the App has started
(I mean until their functionalities are really needed by the app)?
Then this would mean I would have to run ProcessExplorer a few
times while I play around with the app to see if additional DLLs
are loaded.
3) Think about which DLLs are normally present on user's installations of Windows and add those that are likely not to
be present. I still regard this to be a hard thing since one
can never know what the user has and has not installed. Someone
was so kind and enlighten me a bit about this in another thread.
Thanks again for the answers, also to Prakash. Codeproject is a wonderful treasure of knowledge and helpfulness and I hope to give back some day when I have learned enough to do so.
Tony
|
|
|
|
|
Tony Westminster wrote:
could it be the case, that some DLLs are loaded only after the App has started
Yes, this is what LoadLibrary() and GetProcAddress() are for.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I dont think its possible to determine explicitly linked dlls, may be if you look into the exe file using some hex viewer software and search for dll you can find all the dlls that are linked explicitly and implicitly..
but then it also has some limitation for example, the utility regsvr32 loads the dll dynamically and the input dll is a parameter, here you can never determine which dll it is loading dynamically.
|
|
|
|
|
This is a warning about a DLL an operating system DLL uses. That operating system DLL is smart enough to not load the DLL if it isn't present. It uses the delay loaded DLL system to do this.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hi
I currently want to use a function which takes in a BITMAPINFOHEADER as its argument. The problem is, I have to obtain it from a bmp file, and I don't know how I can obtain BITMAPINFOHEADER structure from the file.
I know I can use LoadImage function to load a bmp file, but as far as I know, in this case its return value is an HBITMAP handle, which is used to create a CBitmap object. I also know that we can specify the LR_CREATEDIBSECTION flag when we call LoadImage, although frankly speaking I am still unsure what it does. Is there a way to get BITMAPINFOHEADER from CBitmap? Or should I go take another route to get the BITMAPINFOHEADER?
Thanks!
|
|
|
|
|
Indrawati wrote:
...I don't know how I can obtain BITMAPINFOHEADER structure from the file.
CFile fileBitmap;
BITMAPFILEHEADER rBitmapFileHeader;
BITMAPINFOHEADER rBitmapInfoHeader;
if (fileBitmap.Open(strFilename, CFile::modeRead, &rFileException) == TRUE)
{
fileBitmap.Read(&rBitmapFileHeader, sizeof(BITMAPFILEHEADER));
fileBitmap.Read(&rBitmapInfoHeader, sizeof(BITMAPINFOHEADER));
...
}
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Hi,
My question is, I have been writing one simple VC++ program, which is related to file transfer using FTP software. I have FTP server software which is actually a third party software(exe file) and runs in one system. Through my VC++ program, i sending some FTP built in commands like Get,put..etc...
My problem is, to execute this FTP commands, i have used a command called "system" and the FTP console output redirected to one Text file. Ultimately i have to calculate the throughput, so now if i transfer the data only one time, then it is no probs, but when i transmit with counter continuously,
say for example, if count=10; transmit and receive 10 times and append the FTP console output in the same file. I have to read a particular line of FTP console output and there will 10 FTP console outputs, so i have to take the average number of bytes and secs. After that i need to display over gui.
Another problem is, when a customer finished the process for only one time and if he runs the program again, the FTP console output will be redirected to the same existing text file. Again i have to find out which the latest transmission and which is the line i have read.
could you please give me some idea to solve this simple issue.........
My question may be simple but i couldn't solve it since i am a learner.....
Peroz babu
|
|
|
|
|
This sounds like a job for sockets, specifically socket 21. Here are some examples.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Hi, how to set form/control width and height in VC++ IDE or in code? I mean, if i want it
to be exactly 100x200pixels, how do i do that? Is there anything similar to Visual Basic?
I have a simple program that adds two numbers in array using MMX (inline assembly), the program works fine, the code as shown below,
The result on screen is :
70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93
which is correct,
however, if i change the line
char incamt[]={u,u,u,u,u,u,u,u};
to
char *incamt;
incamt=new char[8];
for(int j=0;j<8;j++) incamt[j]=u;
the program compiles but the result is wrong! Why is that?
Output:
9 82 117 68 17 18 19 20 17 90 125 76 25 26 27 28 25 98 -123 84 33 34 35 36
#include "stdafx.h"
#include <iostream.h>
void main()
{
const u = 5;
//an array of increment amounts to aid SIMD-style operation
char incamt[]={u, u, u, u, u, u, u, u};
//instr is an array of 24 bytes
char instr[]={65,66,67,68,69,70,71,72,73,74,75,
76,77,78,79,80,81,82,83,84,85,86,87,88};
//the following is an embedded assembly code which
//uses MMX instructions to add in parallel the
//amount u to all the bytes of the array instr
__asm
{
movq mm1,incamt //mm1 has value u in all its 8 bytes
mov cx, 3 //initialize loop count
mov esi, 0 //initialize index register
L: movq mm0, instr[esi] //mm0=next 8 bytes from instr
paddb mm0,mm1 //parallel add 8 bytes of mm0 & mm1
movq instr[esi],mm0 //move result to instr
add esi, 8 //update index register
loop L //loop back
emms //empty MMX state
} //end of assembly code
//C++ code to output the results for verification
for (int i=0;i<24;i++) cout<<int(instr[i])<<" ";
="" cout<<endl;
="" just="" to="" pause="" the="" screen
="" cin="">>i;
} //end of main
|
|
|
|
|
Hi,
I have a bit of code that works fine in non MFC C++ project. However when converting to MFC code I get the infamous C2664 compiler error. This is what I'm trying to do:
<br />
double CWork::Equation(double x[])<br />
{<br />
return (100*(x[1]-x[0]*x[0])*(x[1]-x[0]*x[0])+(1.0-x[0])*(1.0-x[0]));<br />
}<br />
<br />
double CWork::DriverFunc(double (*dblfunc)(double[]), double start[])<br />
{ <br />
min = lots of operations;<br />
return min;<br />
}<br />
<br />
void CWork::WorkIt()<br />
{<br />
double start[] = {1.,2.,3.};<br />
double min;<br />
int i;<br />
<br />
min=DriverFunc(Equation,start);<br />
}<br />
This is the error: Work.cpp(1041) : error C2664: 'DriverFunc' : cannot convert parameter 1 from 'double (double []) const' to 'double (__cdecl *)(double [])'
Any suggestions would be great.
Kash
|
|
|
|
|
Yes. You are trying to send a MEMBER FUNCTION as a "regular" (global-scope) function to CWork::DriverFunc().
You can't send pointers to member functions as "regularly" as you send pointers to "regular" functions. The discussion on this is long, and you would have no problems finding the reasons on the web. It's too long to be included here.
In any case, you have three basic options:
1) If you don't care that DriverFunc() will get a CWork-method (rather than "any" function returning double and accepting a double-array), you can change it's prototype to:
typedef double (*CWork::dblfunc)(double[]);
double CWork::DriverFunc( dblfunc func, double start[] )
{
...
}
2) Instead of passing "Equation" to DriverFunc, pass an intermediate function which will call Equation. This function will be a static member of CWork, so even if Equation() is "hidden" it will still be able to call it. This also means you'll have to pass "this". Here's how it goes:
static CWork::CallEquation( CWork* That, RestOfParamsForEquation )
{
That->Equation( RestOfParamsForEquation );
}
and then:
typedef double (*WrapperForEquation)( CWork* That, RestOfParamsForEquation );
CWork::DriverFunc( WrapperForEquation w, double start[] )
{
...
( Whever you want to call the passed function, use w(this,ParamsYouWouldLikeToPass) )
}
And then in WorkIt(), call DriverFunc with CallEquation() as the first argument
3) The third option is THE ugliest by far, slightly more complex, but does EXACTLY what you want. It will only work if Equation() satisfies a list of requirements (non-virtual, non-static), is NOT portable, and like I said: ugly. But it actual usage it's the simplest, and I like it...
The idea is basically to circumnavigate the compiler's type checking system (which is what yells at you in the first place), which WILL allow you get the address of CWork::Equation. You would have to use the value with care, but it can be done. I'll elaborate more if you want, but like I said: it's ugly...
Good luck.
-- Calius
|
|
|
|
|
Simple solutions have their own beauty 
In Equation(), I will eventually need to use member variables from my CWork class so I think the first method won't fit the bill.
Please elaborate on the third option.
Kash
|
|
|
|
|
All options will work for you, since all options will result with DriverFunc() being called on the correct object. The way I usually do it is option (2), actually. It's a small price to pay (1 line of code) for the generic mechanism you gain.
Just in case we're not talking about the same thing when we're saying "option (2)", here's what I mean (in an all-madeup example):
Let's say you have a function (or a method of some class) which needs to call some "callback" function with three parameters: an int, a double, and a char. It's customary anyways to add a "context" or "userdata" argument to such callback functions (even in plain C) so you can use the same function for several callbacks, and each of the callers will pass a different first argument ("userdata") according to what was requested when the cb func was registered.
In our case we replace this "context" / "user data" with a pointer to the actual C++ instance.
We define a type for the cb func: ClassMethodCbFunc -- it gets our int,double,char arguments, plus another parameter which will become the "this".
-------------------------------------------------------------------------------------------
typedef int (*ClassMethodCbFunc)( void* This, int Param1, double Param2, char Param3 );
// (Note: "This" and not "this" !)
-------------------------------------------------------------------------------------------
The function (or some class method) which wants to use this type looks like:
-------------------------------------------------------------------------------------------
void FunctionWhichCallsMethodCb( ClassMerhodCbFunc Func, void* This )
{
...
int Res = Func( This, 1, 2.0, 'c' );
...
}
-------------------------------------------------------------------------------------------
... that is: it calls it's "Func" argument with the "This" parameter it receives, and the values for Param1, Param2 and Param3 can be anything. ("Func" and "This" go together: when one is passed for a func to another, so will the other one. Just like the "CbFunc" and "userdata" in "plain" C).
Now for the class which actually contains the method that will eventually be called:
-------------------------------------------------------------------------------------------
class CMyClass
{
public:
int MemthodBeingCalled( int Param1, double Param2, char Param3 )
{
return Param1 + Param2 + Param3;
}
static int MethodBeingCalled__Wrapper( void* This, int Param1, int Param2, char Param3 )
{
return ((CMyClass*)This)->MethodBeingCalled( Param1, Param2, Param3 );
}
}
-------------------------------------------------------------------------------------------
... Note MethodBeingCalled__Wrapper: it's static, so we can take it's address. (It does NOT receive a hidden "this" argument, since it's static!).
The way to actually use of all of this:
-------------------------------------------------------------------------------------------
CMyClass MyInstance;
FunctionWhichCallsMethodCb( CMyClass::MethodBeingCalled__Wrapper,
&MyInstance );
-------------------------------------------------------------------------------------------
Finally -- regarding the (in)famous "option (3)" :
In a nutshell, you can't take the address of class methods if they're virtual (or you can, but the function whose address you'll be getting will be resolved in linkage, not run-time, so you won't be getting the "latest implementation" -- always the same class name you mention). Also, you need to be aware of calling conventions etc...
The idea I found was this: you can circumnavigate the type checking by using a mechanism designed just (well... sorta) for that: ellipses.
If you write a function such as
void* ToVoidStar( void* Dummy, ... )
{
// Use "va_list" here to get the first argument and return it as a void*
}
And call it like:
void* Addr = ToVoidStar( 0, CMyClass::SomeMethod )
you will get the address of CMyClass::SomeMethod() in "Addr".
You then need to write a function to CALL such the method pointed to by "Addr" -- it's not a simple matter of casting it to a function-pointer type and calling it via the pointer, since in __stdcall "this" is passed in ECX.
So we need some small function, a "thunk", which accepts a "this" pointer, some parameters, and does "mov ecx,[This] ; push PARAMS ; call [Func]" (rough sketch, of course...).
This will only work for __stdcall functions, of course, which are (basically) all methods with a constant number of arguments (not ellipses!).
Maybe I should write an article on this?
-- Calius
|
|
|
|
|
Thanks for your help. I was just thinking whilst reading half way down, that you should write an article on this subject. People will definitely benefit from this.
I solved the problem using ideas from your reply and now all seems to work fine.
Thanks again.
Kash
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
