|
you said "cannot convert parameter 1 from 'wchar_t *' to 'char *" whats error? and i said use OLE2A
whitesky
|
|
|
|
|
Guys this is the code but cant read the unicode file...........
if there is any problem in it tell me i will solve it..........
FILE* fp = NULL;
wchar_t* buf = (wchar_t*)malloc(sizeof(wchar_t) * 200);
wchar_t* retbuf = NULL;
if ((fp = fopen("d:/GRCasual.txt", "r")) == NULL) // opens the file
{
return 0;
}
while(!feof(fp))
{
/*fseek(fp,sizeof(char),SEEK_CUR); */
retbuf = fgetws(buf, 200, fp);
}
if( fp )
fclose(fp);
return 0;
thnx in advance
regards
Rakesh
|
|
|
|
|
How could i judge the Cd-rom door's status?(open or closed). Pay attention to that here is Cd-rom not DVD-rom, I used the SCSI command "Mechanism Status" to get the dvd-rom door's status successfully, but it can't work on Cd-rom, so what should i do to fix this trouble?
Go go go, roger that. Enemy sighted!
|
|
|
|
|
U look into DeviceIoControl() with IOCTL_STORAGE_EJECT_MEDIA as a second parameter.
Jubin Chawda
braindrain1@rediffmail.com
-----------------------------
Come online at:-
fitiyal@yahoo.com
|
|
|
|
|
|
Thanks you all for your helpful infos, but all seems not work fine.
Is there a command of SCSI just as same as "mechanism status" command which can work on DVD-ROM?
Or some other helpful infos?
|
|
|
|
|
|
Thanks for your help, whitesky!
But I wonder if you really understand what I want to realize!
I just want to know the status of CD-ROM, it is opened or closed?
The MCI command can't work at all, I tried it before, and WM_DEVICECHANGE message also can't work. And I tried MMC command(APSI programming),but it can only work on DVD-ROM, do not work on CD-ROM! That's my trouble.
My original purpose is that if you right click the CD/DVD-ROM icon, the eject menuitem can take a little change for it can change to "Insert" if the door is already opened, and back to "eject" if the door is closed. For this, I must know the status of the door, it is closed or open?
One day a pretty girl asked me: "Do you think you are handsome?"."I don't think so!" She gave a slap in my face:"Why lying?"
|
|
|
|
|
Hello everyone,
I am meeting with a strange linking error regarding to operator overloading. I am creating a C++ static lib, and then linking it with a C application. Here is the error message and source codes,
I am using adapter.cpp, adapter.h, foo.cpp and foo.h to create a static lib called foo.lib, then link it with a C application (goo.c). There is no problem to generate the static lib foo.lib.
Any comments to solve this link error?
<br />
error LNK2019: unresolved external symbol "private: class FooNameSpace::Foo __thiscall FooNameSpace::Foo::operator=(long)" (??4Foo@FooNameSpace@@AAE?AV01@J@Z) referenced in function "private: __thiscall FooNameSpace::Foo::Foo(<br />
long)" (??0Foo@FooNameSpace@@AAE@J@Z)<br />
<br />
fatal error LNK1120: 1 unresolved externals<br />
adapter.cpp
<br />
#include "adapter.h"<br />
#include "foo.h"<br />
<br />
using namespace FooNameSpace;<br />
<br />
void compute(void)<br />
{<br />
Goo g;<br />
g.computeFoo();<br />
}<br />
adapter.h
<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
void compute (void);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />
foo.cpp
<br />
#include "foo.h"<br />
<br />
using namespace FooNameSpace;<br />
<br />
Foo Foo::operator=(long value)<br />
{<br />
this -> value = value;<br />
return (*this);<br />
}<br />
foo.h
<br />
namespace FooNameSpace<br />
{<br />
class Foo<br />
{<br />
<br />
private:<br />
long value;<br />
<br />
Foo (long value) { (*this) = value; }<br />
inline Foo operator= (long value);<br />
friend class Goo;<br />
};<br />
<br />
class Goo<br />
{<br />
public:<br />
void computeFoo()<br />
{<br />
Foo foo = Foo(0L);<br />
}<br />
};<br />
}<br />
goo.c (link with foo.lib)
<br />
#include "adapter.h"<br />
#include "windows.h"<br />
<br />
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,<br />
LPWSTR lpCmdLine, int nCmdShow)<br />
{<br />
compute();<br />
return 0;<br />
}<br />
thanks in advance,
George
|
|
|
|
|
I think no error will be generated if you:
- remove the
inline keyword from the declaration of Foo::operator =; - or, move the implementation of
Foo::operator = from foo.cpp to foo.h file; - or, place the implementation of
Foo::operator = function inside the Foo class.
I hope it helps.
|
|
|
|
|
Hi Viorel!
Your method is so magic and it works! What is the reason of my linking error and why your method works?
regards,
George
|
|
|
|
|
As I know, when we work with inline functions, then the body of such items must be provided in .h files, not in .cpp ones. This is because the compiler needs the source code of such functions in order to insert them into compiled code, thus making them "inline".
If we implement a function in a .cpp file, then the compiler makes a binary .obj or .lib file, and the source code is lost. Therefore the compiler will be only able to generate a call to such functions, but not make them inline.
This is also true for template classes and template functions -- they must be delivered in header files. (For instance see STL).
However, it seems that future compilers will allow implementation of inline and template items in .cpp files.
|
|
|
|
|
Thank you Viorel!
Viorel. wrote: As I know, when we work with inline functions, then the body of such items must be provided in .h files, not in .cpp ones. This is because the compiler needs the source code of such functions in order to insert them into compiled code, thus making them "inline".
It should be the linker not the compiler to insert implementations into compiled code, right?
Viorel. wrote: If we implement a function in a .cpp file, then the compiler makes a binary .obj or .lib file, and the source code is lost. Therefore the compiler will be only able to generate a call to such functions, but not make them inline.
Do you mean we need to insert the source codes of inline function into the modules which invoke inline functions?
I think ordinary function (non-inline function) does not need to insert source codes into the modules which invokes the ordinary function, right? And what did the linker/compiler do when dealing with ordinary function in the same situation?
regards,
George
|
|
|
|
|
In my vision, when we call an inline function from 100 different places, the body of function is inserted in each such a place, and then the entire code is compiled. Only compiler can do this task. That’s why we need to supply the source code of inline function to the compiler.
The linker cannot do such task. Linker only assembles compiled code (.obj and .lib files).
In case of non-inline functions, they are compiled once into an .obj or .lib file. In the modules, to the compiler we need to supply only the declaration of such functions. If we call such function from 100 different places, then the compiler will generate a CALL microprocessor instruction in each place, but without an address. The address will be inserted later by the linker.
That’s my opinion.
|
|
|
|
|
Thank you Viorel!
If it is the compiler who inserts source codes implementation of an inline function into the place when we invoke the function, I think there should be compiling errors other than link errors in my situation, right? But why when I build the foo.cpp, foo.h, adapter.cpp and adapter.h into a static library (foo.lib), there is no error (I think at this time, the compiler should insert the source codes implementation of inline method into the places where inline methods are invoked)?
But the errors are reported when we link the static library into an executable file?
regards,
George
-- modified at 6:34 Monday 3rd July, 2006
|
|
|
|
|
I think when you are building the library file, since the Foo::operator = function was declared inline, the compiler does not generate an entry for it, i.e. this function is not exported. The compiler does not know that you are going to use it in another place. (I suppose the list of exported functions can be checked with dumpbin utility).
I think when compiler builds a file in which an inline function is called, but no body of this function is available, then the compiler treats this as a non-inline function, and expect it to be implemented somewhere. (Maybe it would be better to show a warning message here).
Because the linker was not yet invoked during compilation of your static library, no problems occur yet.
Errors occur later when the linker cannot link your module because of missing external function.
|
|
|
|
|
Thank you Viorel!
Viorel. wrote: I think when you are building the library file, since the Foo::operator = function was declared inline, the compiler does not generate an entry for it, i.e. this function is not exported. The compiler does not know that you are going to use it in another place. (I suppose the list of exported functions can be checked with dumpbin utility).
Why inline function is not treated as exported? I think foo.cpp exports the inline operator overloading function by the following statement (the first line of function definition),
<br />
Foo Foo::operator=(long value)<br />
Maybe I am wrong. Could you explain how (in what form) an function can be exported (in my previous comprehension, I think non-static function, which means not locally used function, like the above function, is exported automatically)?
Viorel. wrote: I think when compiler builds a file in which an inline function is called, but no body of this function is available, then the compiler treats this as a non-inline function, and expect it to be implemented somewhere. (Maybe it would be better to show a warning message here).
Do you mean the when the compiler builds foo.cpp or adapter.cpp or goo.cpp? Confused.
regards,
George
|
|
|
|
|
A function is "exported" from .obj or .lib binary files means that there is an address which points to the beginning of the compiled function. This address is used by linker to generate the CALL microprocessor instructions. If a function is marked as inline, then no such address is stored in the .obj or .lib file, because it is supposed that the body of the function will be entirely inserted by compiler instead of CALL instruction.
It seems that only non-inline and not-static functions are exported by .obj and .lib files.
George_George wrote: Do you mean the when the compiler builds foo.cpp or adapter.cpp or goo.cpp?
Yes.
|
|
|
|
|
Thank you Viorel!
Viorel. wrote: A function is "exported" from .obj or .lib binary files means that there is an address which points to the beginning of the compiled function. This address is used by linker to generate the CALL microprocessor instructions. If a function is marked as inline, then no such address is stored in the .obj or .lib file, because it is supposed that the body of the function will be entirely inserted by compiler instead of CALL instruction.
It seems that only non-inline and not-static functions are exported by .obj and .lib files.
I think in my case, in foo.cpp, since it includes foo.h, in which operator =() is declared as inline function, so it is not exported, right?
Viorel. wrote: George_George wrote:
Do you mean the when the compiler builds foo.cpp or adapter.cpp or goo.cpp?
Yes.
Confused. Do you mean them all or one of them? I think it should be adapter.cpp, right?
regards,
George
-- modified at 10:09 Monday 3rd July, 2006
|
|
|
|
|
George_George wrote: I think in my case, in foo.cpp, since it includes foo.h, in which operator =() is declared as inline function, so it is not exported, right?
Yes.
George_George wrote: Confused. Do you mean them all or one of them? I think it should be adapter.cpp, right?
Yes.
|
|
|
|
|
Cool, Viorel!
You have answered my question.
regards,
George
|
|
|
|
|
// the following function is created by (step 4) of the MFC AppWizard
// when you select Use split window from the Windows Style tab of the
// Advanced Options dialog
BOOL CMainFrame::OnCreateClient(LPCREATESTRUCT /*lpcs*/,
CCreateContext* pContext)
{
return m_wndSplitter.Create(this,
2, 2, // TODO: adjust the number of rows, columns
CSize(10, 10), // TODO: adjust the minimum pane size
pContext);
}
i use this code but it does not show mw the split window plz help me how can i see split window
Ashish Dogra
MCA
Noida
|
|
|
|
|
ashish dogra wrote: i use this code but it does not show mw the split window plz help me how can i see split window
The split window is there, just that the default size makes it somehow hidden. Check the scrollbars in your window. Hover your mouse over the left edge (horizontal scrollbar) or top edge (vertical scrollbar) of the scrollbar and you should see your cursor changes. Now drag your splitted window out.
|
|
|
|
|
Hi,
I use a statically linked MFC exe load a statically linked MFC DLL, and careate a CDHtmlDialog in that DLL,
I already add below code to solved original when create CDHtmlDialog will crash problem successfully,
AFX_MANAGE_STATE(AfxGetStaticModuleState());
::OleInitialize(NULL);
AfxEnableControlContainer();
but now when I use it's member function, ex:GetDHtmlDocument
it'll crash,
I already add AFX_MANAGE_STATE(AfxGetStaticModuleState()); to the DLL's each function still have same problem
what else should I add?
Thanks!!
|
|
|
|
|
GetDHtmlDocument retrieves IHTMLDocument2 from html document now whats your problem
whitesky
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
