|
The obvious question is: did you initialise COM?
Steve
|
|
|
|
|
CoInitialize? Where do I add the CoInitialize?
|
|
|
|
|
Somewhere before you use COM.
Steve
|
|
|
|
|
LRESULT CYHtapiCom::OnInitDialog(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
CAxWindow wnd;
CLSID clsid;
LPUNKNOWN pUnkCtrl, pUnkCont;
HRESULT hr = CLSIDFromProgID(OLESTR("VoipTestCom.SimpleClient"), &clsid);
hr = CoCreateInstance(clsid, NULL, CLSCTX_ALL, IID_IUnknown, (void**)&pUnkCtrl);
CComQIPtr spPerStm(pUnkCtrl);
spPerStm->InitNew();
wnd.Attach(m_hWnd);
wnd.AttachControl(pUnkCtrl, &pUnkCont);
return TRUE;
}
|
|
|
|
|
|
Hi
VC++ 2008. I have this web browseron my dialog based MFC app which hosts JavaScript functions thatI access from the app using COM stuff. It worked. I then shifted all the COM related code to a worker thread because that's where I'm receiving data, from the socket, to be displayed on the web browser. And that's where things are not working. I've read things about marshalling which needs to be done if COM is to be accessed from or accross threads. But I can't figure out where to start!
spDisp = m_ex->get_Document();
spDisp->QueryInterface(IID_IHTMLDocument2,(void**)&m_spDoc);
m_spDoc->get_Script(&spScript);
This is the code, copied form some example on the web. m_ex is the pointer to the CExplorer1 object (the web browser control). The program crashes on the last line. Can someone please guide me what to do exactly so that it runs in the thread? Thanks.
|
|
|
|
|
At a guess I would say that the second line failed, so m_spDoc has not been given a valid pointer. You should check the results of your API calls to see if they succeed or not, as described in this MSDN page[^].
Use the best guess
|
|
|
|
|
|
I am new to .Net,I have informed all forms of Dll's is used in project, viz., Win32.dll, COM'Dll, and .Net Dll's, I need to find how we can identify .Net Dll's,
however though, I could identify COM'Dll using DllRegisterServer as search attribute.(InProcServer) in entire Solution. ie., using VS 2008 IDE, the above keyword "DllRegisterServer" relating to all COM Dll's was found.
But, Is there a Similar way to identify .Net Dll's ??
Details:
VS 2008 IDE, Win 7 O/S, Project using .exe,.dll's etc.,
With Regards,
VishalK_89
|
|
|
|
|
Please do not post the same question in multiple forums; choose one and stick to it.
Use the best guess
|
|
|
|
|
Windows 7, Visual Studio 2008, MFC, C++
This solution uses source code from directory D:\COMMON_CODE. To test some things the solution was copied to a new directory. It will not compile. There are several errors, all of the format:
1>c1xx : fatal error C1083: Cannot open source file: '..\..\..\..\COMMON_CODE\C_Log_Writer.cpp': No such file or directory
I did not enter "..\..\" etc when configuring the solution/project.
In the solution explorer, right click on the project and select Properties. From there select Configuration Properties -> C/C++ -> Additional Include Directories. In there is the above named directory. Just as it was before the copy operation. Clean Solution" was performed as was a direct compile of stdafx.cpp. The error remains.
The solution has the information of where to look for these files. What do I need to do to get it to look there?
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
not exactely sure where/what your problem is ...
Are all your 'Cannot open source file' errors related to files under 'COMMON_CODE' directory ?
This is what I would do if all the errors ARE related to files under 'COMMON_CODE' - (and I'd use Windows Explorer and find to check where they are)
a) set an environment variable to where COMMON_CODE is - that is, I'd set a Permanent System variable - eg COMMON_CODE and point it to Drive:\Path\COMMON_CODE
b) restart the machine
c) In VS2008, open your project, Under 'Additional Include Directories', include ${COMMON_CODE} (I think you need a space between this and the other directories iirc)
When you move directories in future, you change the environment variable, not the project. I do this particularly for 3rd party libraries, where I might need to point to different versions of a library.
You still have to point it to the correct location, in either case/whichever way you're doing it, it looks like your 'Additional Include Directories' setting is still wrong
'g'
|
|
|
|
|
Re: Are all your 'Cannot open source file' errors related to files under 'COMMON_CODE' directory ?
Yes, they are. The entire solution compiled and ran as expected. Then I copied the entire solution to another location. The build then began reporting that it could not find any of the files in directory D:\COMMON_CODE.
Re: You still have to point it to the correct location, in either case/whichever way you're doing it, it looks like your 'Additional Include Directories' setting is still wrong.
I don't see how it can be wrong. The common directory did not move, but the entire solution did. The additional directory location is being converted to a relative location directory. The configuration section does not specify a relative location, it specifies an absolute location.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
Garth J Lancaster wrote: c) In VS2008, open your project, Under 'Additional Include Directories', include ${COMMON_CODE} (I think you need a space between this and the other directories iirc)
The include directories should be a semicolon-separated list. The directories themselves may (or may not) contain spaces.
In the bigger picture, I endorse this way of specifying directories.
If I understand the original problem properly, OP used a full filespec for an include directory. Visual Studio likes to keep track of file and directory locations relative to the location of the project file (or solution file, depending on things). If you get a solution/project working in one location (which points to an absolute file/folder location) and then copy the solution/project to another location, the 'relative' file/folder pointers will be wrong. Garth's solution should fix that part of the problem.
--
Harvey
|
|
|
|
|
Have you tried deleting all temporary files, including precompiled headers?
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
|
I deleted the dot NCP file where the project file is located. I deleted the all the files in the release directory and all the files in the debug directory. All to no avail.
I removed the D:\COMMON_CODE from the configuration, cleaned, recompiled, re-added it, and same results. It still refuses to find the files in the common directory. The errors show a relative directory location based on the original location.
What other files might I try to delete.
The same project continues to build in the original location.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
Perhaps I am missing something here. The sample you have shown is for a .cpp file. This suggests to me that this is not a problem with your "Additional Include Directories", but that those files were included into your project with the relative path. I would open up the .vcxproj (if that is the extension used for 2008) and look at the path specified for that file.
As an example from one of my projects, there are files included like this:
<ItemGroup>
:
<ClCompile Include="StdAfx.cpp">
:
:
</ClCompile>
<ClCompile Include="..\..\Libraries\include\Packets\Stream.cpp">
:
:
</ClCompile>
:
</ItemGroup>
Obviously if you just copy the solution to a folder with a different nesting level, that will mess things up.
[EDIT]Updated the entries from my sample to show the .cpp files instead of the .h files[/EDIT]
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
File Project_Client_.vcproj contains:
<Tool
Name="VCCLCompilerTool"
Optimization="0"
AdditionalIncludeDirectories="D:\COMMON_CODE"
PreprocessorDefinitions="WIN32;_WINDOWS;_DEBUG"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="2"
WarningLevel="3"
DebugInformationFormat="4"
It has the absolute location of the include files. I presume that is correct.
Re: Obviously if you just copy the solution to a folder with a different nesting level, that will mess things up.
I don't see why. Everything within the solution proper is in the same relative locations. Only this directory is in the stated absolute location. The problem is only with the common code directory, and it has the correct path for that. Same as the original location.
Edit: But then in another place in the same file is this:
<Files>
<Filter
Name="Source Files"
Filter="cpp;c;cc;cxx;def;odl;idl;hpj;bat;asm;asmx"
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
>
<File
RelativePath="..\..\..\..\COMMON_CODE\C_Log_Writer.cpp"
>
</File>
<File
RelativePath="..\..\..\..\COMMON_CODE\C_TCP_Client.cpp"
>
So it has the location in both relative and absolute position. That appears to be the worst of both worlds. How do I tell VS to recalculate all the relative positions.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
But that is because the "Additional Include" directories is for including header files.
Let me ask you this: If you double-click on your C_Log_Writer.cpp in your solution, is it found and opened in the IDE? I do not expect it to be if the relative path specified in you project file is now incorrect.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
Upon clicking on C_Log_Writer.cpp VS pops a message:
d:\B\COMMON_CODE\C_TCP_Client.cpp Cannot open file.
The solution is in directory D:\B\etc. The common code is in D:\COMMON_CODE like I explicitly specified in the configuration. It has no business putting that \B\ in there. I say again, the additional directories was specified as an absolute path, not a relative one. The original solution had both the dot CPP and the dot H file added. All were shown in the solution explorer.
Edit:
While in that configuration section of VS and with Additional Directories selected, press F1. In there it has an example that includes MAIN.C. I do not see it as limited to dot H or dot HPP files.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
modified 24-Mar-13 20:21pm.
|
|
|
|
|
Alright, so it may not be limited to header files, but I cannot remember ever seeing it used for .cpp files. I will refer back to my original answer, the problem is not with your Additional Include Directories, but with the way file references are stored when added to a project.
You may have a point that Visual Studio should use the Additional Include Directories path and save file references without paths (although I would not trust the "find first match" scheme to always find the correct file in case of multiple files with the same name in different Include Directories), but the way you can fix it now seems obvious to me: Correct the paths of the files in your project file. You can even try to just remove the paths completely and see if the files are found using the Additional Include Directories.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
This has nothing to do with include directories, since the file in question is a .cpp not a header file. You need to remove the relevant file(s) from the project and add them in again, using the absolute paths.
Use the best guess
|
|
|
|
|
RE: This has nothing to do with include directories, since the file in question is a .cpp not a header file.
As noted in an earlier reply, the VS help utility has an example that includes MAIN.C. I disagree with that fundamental concept. The dialog does not explicitly or implicitly restrict the use to dot H / HPP files.
Per MacCutchan's reply, removing the files and adding them back in does work. It works, but I am not at all fond of that solution.
That said, and in my not so humble opinion, I find this to be a defect in Visual Studio.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
bkelly13 wrote: The dialog does not explicitly or implicitly restrict the use to dot H / HPP files.
Maybe so, but that is the way the compiler (and by extension Visual Studio) operates. When you want to compile a file, the path and name(s) of the source file(s) to be compiled must be explicitly provided. Any header files that are referred to in the source are searched for according to the rules for that compiler. Most compilers will search the current directory, any directory that contains a named source file, and any directories that are listed in the 'include' lists; these are specified by option, environment variables etc. If the directory path for a source file is incorrect then the compiler will fail that compile and report the error. It will not make any attempt to look in the include directories for it.
bkelly13 wrote: It works, but I am not at all fond of that solution.
Well that's the way it's supposed to work, and always has done.
bkelly13 wrote: I find this to be a defect in Visual Studio.
I think you may be in a minority.
Use the best guess
|
|
|
|
|
Windows 7, Visual Studio 2008, MFC, C++
A memset is not doing what I expect. Here is the relevant code. It is a received TCP/IP payload packet and the goal is to copy some of the data to a new location. m_carry_over_bytes has the expected value of 1200.
All the code surrounding the memcpy is just to look at the before and after.
m_prev_header_packet_size = mp_search_pointer->iads_structure.header.packet_size;
m_prev_header_sequence_number = mp_search_pointer->iads_structure.header.sequence_number;
m_prev_header_packets_sent = mp_search_pointer->iads_structure.header.packets_sent;
m_prev_header_packets_lost = mp_search_pointer->iads_structure.header.loss_or_overflow;
m_prev_header_dummy_0_5555 = mp_search_pointer->iads_structure.header.dummy[0];
m_prev_header_dummy_1_6666 = mp_search_pointer->iads_structure.header.dummy[1];
m_prev_header_dummy_2_7777 = mp_search_pointer->iads_structure.header.dummy[2];
m_prev_header_dummy_3_ffff = mp_search_pointer->iads_structure.header.dummy[3];
memcpy( &m_carry_over_buffer,
&mp_search_pointer,
m_carry_over_bytes );
m_curr_header_packet_size = m_carry_over_buffer.iads_structure.header.packet_size;
m_curr_header_sequence_number = m_carry_over_buffer.iads_structure.header.sequence_number;
m_curr_header_packets_sent = m_carry_over_buffer.iads_structure.header.packets_sent;
m_curr_header_packets_lost = m_carry_over_buffer.iads_structure.header.loss_or_overflow;
m_curr_header_dummy_0_5555 = m_carry_over_buffer.iads_structure.header.dummy[0];
m_curr_header_dummy_1_6666 = m_carry_over_buffer.iads_structure.header.dummy[1];
m_curr_header_dummy_2_7777 = m_carry_over_buffer.iads_structure.header.dummy[2];
m_curr_header_dummy_3_ffff = m_carry_over_buffer.iads_structure.header.dummy[3];
Looking at the m_prev* variables I find the expected values: size is 1228, sequence_number is 62316, ... dummy 2 is 0x7777, etc
After the memcpy, the m_curr* values are expected to have the same values ad the m_prev* values. Instead they have all Fs, the value it was initialized to in the constructor.
Both the source and destination work back to this structure:
union RECEIVE_TYPE
{
char char_array [ C_TCP_MAX_RECEIVE_SIZE ];
C_IADS_TD_FIXED_PARAMETER_PACKET iads_structure;
} m_receive_buffer;
I expected this memcpy to be simple. Where am I not understanding it?
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
modified 11-Mar-13 20:47pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
