|
Christian Graus wrote:
Error 1 fatal error LNK1117: syntax error in option '' dcmmkdir
Now: if I go to the project settings, the command line generated is this :
/Od /I "../../config\include" /I "../../dcmjpeg\include"
That's the command line for the compiler, not the linker
Christian Graus wrote:
I think this bit: /D "CMAKE_INTDIR=\"Debug\"" is the problem, but I can't see where it's set
It should be under C/C++ / Preprocessor / Preprocessor Definitions.
Christian Graus wrote:
there are places that set the directory to build to be debug, but none have the trailing quote
If you look at the Preprocessor Definitions you should find one saying
CMAKE_INTDIR=\"Debug\"
That is, with escaped quotes. When the definition is passed to the command line, it's in turn surrounded by quotes and appended after a /D option. So, the quotes (both escaped and normal) are properly balanced. I don't think that would be a problem.
I'd look at the linker command line
Christian Graus wrote:
Error 1 fatal error LNK1117: syntax error in option '' dcmmkdir
That's what you see in the "Error List" or "Task List" tab, right? If I interpret it right, dcmmkdir is just the name of the project in which the error occurred and not part of the error message itself, which is in another column. If I got it right, then, the actual error is saying there is a syntax error in option '' (note it's not a quote, but actually an empty option surrounded by single quotes)... That's odd...
Look at the wording in the Output window, which will show the exact output from the linker. Maybe that would shed some light and point you in the right direction.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Doh !!! I didn't have the output window visible.
This is what I get for one of them:
LINK : fatal error LNK1117: syntax error in option ''
Project : warning PRJ0018 : The following environment variables were not found:
$(INT /LIBPATH:../../dcmimgle\$(INTDIR)
I'm finding that the link extra commands is perhaps too long, I'm replacing it with explicit paths to any lib files it reports it needs, that seems to be going OK, so far.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
$(INT /LIBPATH:../../dcmimgle\$(INTDIR)
That looks like an incomple $(INTDIR) macro, which stands for Intermediate Directory. That macro is used for "Debug" or "Release" depending on the configuration you are building. It seems like since the macro got truncated (i.e.: $(INT instead of $(INTDIR) ), the linker kept looking for the closing parenthesis and interpreted all that (including the next libpath) as a macro, which then of course couldn't find.
Look for $(INT followed by a blank space in Linker / Command line / Additional options or in Linker / General / Additional Library Directories, and complete the macro. That should work.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
I don't think any of these are mangled, I've been looking at them all day. It seems more likely that they are being truncated, because the list is so long. At least, some info I found on the web suggests this to be the case. I'm abandoning this list, and adding paths to the additional include directories for each file, which has worked for 2 of the 5 projects so far ( I've been sidetracked from doing the rest ).
Thanks for your help.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I was curious so I downloaded and opened this project with VS2005 (don't have VS2003 in this machine) and the options are definitively mangled.
There are around 270 options, most of which are duplicated (each libpath is repeated around 7 or 8 times). Besides that, I found:
3 cases of a single slash with nothing else. That would explain that LNK1117 with an empty option in your first post.
One option saying:
/LIBPATH:../../../zlib-1.2.1\lib\$(INT
and followed by:
/LIBPATH:../../dcmimgle\$(INTDIR)
That's the last error you post.
One option saying:
/LIBP
which is probably an error too.
One option saying:
/LIBPATH:../../../ti
which is probably a truncated version of
/LIBPATH:../../../tiff-3.6.1\lib\
One option saying:
/LIBPATH:../../d
which is probably a truncated version of
/LIBPATH:../../dcmdata\
or any of the other paths starting with 'd'
And many others that seem similarly truncated.
All these problems may be related to errors in the conversion from a VC6 project to VS2003/2005.
Did you use the CMake utility as indicated by the instructions in the Install file? If I understood it right, that's the proper way to convert it to VS2003.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
No, I found the instructions about CMake, but initially I just saw a VS2003 project and expected it to work. Why would they have a broken project file in there, I don't get it ?
Anyhow, I've nearly got it building, if I have more trouble with it, I'll go back to CMake. The reason for this is that this library links into the project that I've moved to VC2005, and I get a lot of basic_ostream linking errors on this library, so I need to be able to compile it to figure out the problem and fix it.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I've got a list control that I'm using for different profiles in my app. When I add a profile to the control it lists it correctly. However when I delete a profile I cannot get the control to move up the icons so that they are taking up the space. Is there a way to move the icons up without reloading the list control?
Thanks
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
Tom Wright wrote:
Is there a way to move the icons up
I'm not sure if I got your question right, but maybe you are looking for this method:
CListCtrl::Arrange[^]
Or you might use the LVS_AUTOARRANGE style.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Thanks that did it.
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
Hey all, Im having a problem with passing a var to a function via AfxBeginThread. It appears the function is being called properly, but my data, which is in the form of a pointer to one of my ServerData classes, appears corrupted in the eyes of the thread function (debugger shows data as it should be before call, inside thread function, everything is chaotic).
This is the code the starts the thread (triggered by a CListView message):
<br />
LPVOID ptr = (LPVOID)((ServerData)m_serversList[pNMIA->iItem]); <br />
ServerData* sdat = (ServerData*)ptr;
<br />
CWinThread* thread = AfxBeginThread(&queryServer, ptr);<br />
This is performed at the begining of my thread func:
<br />
UINT queryServer(LPVOID pParam ){<br />
ServerData* server = ((ServerData*)pParam);
<br />
...<br />
}<br />
ServerData's LPVOID cast operator is simply defined as:
<br />
return this;<br />
Any ideas?
|
|
|
|
|
Hi KnaveD,
I would like to interpret the following your statement..
LPVOID ptr = (LPVOID)((ServerData)m_serversList[pNMIA->iItem]);
I can assume that m_serversList[pNMIA->iItem] returns the ServerData object from an array of m_serversList. If you look at your typecasting, it seems to be, it is returning a temporary object, which you are typecasting to a void. That object is not at all a pointer!!!!
Solution
---------
If I am not wrong, you can modify your code like this..
LPVOID ptr = (LPVOID)((ServerData*) &m_serversList[pNMIA->iItem]);
ie to get the address of the array element..
" Action without vision is only passing time,
Vision without action is merely day dreaming,
But vision with action can change the world "
- Words from Nelson Mandela
Thanks & Regards,
Gopalakrishnan
|
|
|
|
|
Hi, all
I have installed the WINDBG and trying to use it for VC6, my question is how to open up and memory dump in VC6 and attach to the source code? could it be done for VC98?
The reason I am trying this is the release version of application crashed on one testing box with "application error" and not happening on my side.....so I installed the WINDBG in test box and created the memory dump.....
any info will be greatly appreciated.
|
|
|
|
|
You are probably better off to open the memory dump in the WINDBG.
WINDBG makes a 'fuller' memory dump than the VC6 can understand.
If you fill in the WINDBG folders for symbols and source files, it will lead you to exactly the source file and line where the crash occurred, based upon the information in the DMP file.
Open the DMP file first.
Set the 'symbols' path to point to your PDB files that EACTLY match the release build the customer has.
Set the path leading to your source files.
Issue a .reload in the WINDBG command window.
Execute a 'g' command to 'go' and it will lead you to the crash.
|
|
|
|
|
BOOL CMyApp::InitInstance()
{
m_pMainWnd = new CMyFrameWnd;
m_pMainWnd->ShowWindow(m_nCmdShow);
m_pMainWnd->UpdateWindow();
return TRUE;
}
I change it to the next code block,but I got some error
BOOL CMyApp::InitInstance()
{
m_pMainWnd = new CMyFrameWnd;
::ShowWindow(hWnd,m_nCmdShow);
::UpdateWindow(hWnd);
return TRUE;
}
Is there any WIN32API can change "m_pMainWnd" to "hWnd"??
shanzy1980
|
|
|
|
|
It has a m_hWnd property, from memory. MFC is a wrapper for Win32, so it's all in there.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Thank you!
But when I code like this:
::ShowWindow(m_hWnd,SW_SHOWNORMAL);
I got a error: error: identifier "m_hWnd" is undefined
I want to know which WIN32API can change a handle to a pointer to Class??
shanzy1980
|
|
|
|
|
I meant m_pMainWnd->m_hWnd, and I said I *think*, I expected you'd use intellisense to work out how close I was.
shanzy1980 wrote:
::ShowWindow(m_hWnd,SW_SHOWNORMAL);
Ah.... If you call ShowWindow without the ::, I think there's a method on the class. Or you can do this:
::ShowWindow(*this, SW_SHOWNORMAL);
because when you deference the point, there's an operator HWND.
shanzy1980 wrote:
I want to know which WIN32API can change a handle to a pointer to Class??
None, that can't work. Win32 came first, so the framework knows about Win32, Win32 does not know about MFC. Win32 is for use in C as well, so it cannot support classes at all.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I'm a beginer,and now I read the book《Programming Windows with MF,second Edition》,this is the source code:
//myfirst.h
class CMyApp:public CWinApp
{
public:
virtual BOOL InitInstance();
};
class CMyFrameWnd:public CFrameWnd
{
public:
CMyFrameWnd();
protected:
afx_msg void OnPaint();
DECLARE_MESSAGE_MAP()
};
////////////////////////////////////////////////
#include <afxwin.h>
#include "myfirst.h"
CMyApp theApp;
BOOL CMyApp::InitInstance()
{
m_pMainWnd = new CMyFrameWnd;
::ShowWindow(*this,SW_SHOWNORMAL);
::UpdateWindow(*this);
return TRUE;
}
BEGIN_MESSAGE_MAP(CMyFrameWnd, CFrameWnd)
ON_WM_PAINT()
END_MESSAGE_MAP()
CMyFrameWnd::CMyFrameWnd()
{
Create(NULL, _T("myfirstMFC"));
}
void CMyFrameWnd::OnPaint()
{
CPaintDC mydc(this);
CRect rect;
GetClientRect(&rect);
mydc.DrawText(_T("MFC"),-1,&rect,DT_SINGLELINE|DT_CENTER|DT_VCENTER);
}
It also don't work, If you can explain with circumstances why it doesn't work
Thanks!
shanzy
|
|
|
|
|
Well, what do you mean when you say it doesn't work ? Does it have errors ? Does it not do what you're expecting ? I'll try to recreate this project locally and see what I can find, but any info you can give on the difference between what you're seeing and what you're expecting would help me to help you.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I got a LINK error:
catastrophic error: #error directive: Please use the /MD switch for _AFXDLL builds
#error Please use the /MD switch for _AFXDLL builds
|
|
|
|
|
You're using VC6  ( I worked that out by looking at the code, not the error ). VC6 is kind of crap, but it's OK for learning. When you get to understand C++, you'll want to upgrade.
I'd say this means you have your app running at the same time as the compiler is trying to write to it, that's all. If it's not visibly running, hit CTRL-SHIFT-ESC for the task manager, look through the processes and kill it there.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
OK,I know it,Thank you very much!!
|
|
|
|
|
shanzy1980 wrote:
I change it to the next code block,but I got some error
Why do you want to change it? MFC's CWnd (and derived classes) are wrappers around window handles (those hWnd you see here and there). I can understand that if you obtained an hWnd somehow (e.g.: creating a window yourself using one of the API functions) you may not want to create an MFC CWnd class to wrap it, but if you already have one of the CWnd objects, why would you want to use the API directly instead of using the corresponding class methods?
Anyway... In your code:
BOOL CMyApp::InitInstance()
{
m_pMainWnd = new CMyFrameWnd;
::ShowWindow(hWnd,m_nCmdShow);
::UpdateWindow(hWnd);
return TRUE;
}
After m_pMainWnd = new CMyFrameWnd, m_pMainWnd points to a CMyFrameWnd object, but the window won't be still created (unless you added some code to the class constructor to do it).
In ::ShowWindow(hWnd,m_nCmdShow); and the next line, hWnd is undefined.
The translation from CWnd methods to API calls should be like this:
BOOL CMyApp::InitInstance()
{
m_pMainWnd = new CMyFrameWnd;
::ShowWindow(m_pMainWnd->m_hWnd, m_nCmdShow);
::UpdateWindow(m_pMainWnd->m_hWnd);
return TRUE;
Hope that helps,
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
shanzy1980 wrote:
m_pMainWnd = new CMyFrameWnd;
::ShowWindow(hWnd,m_nCmdShow);
::UpdateWindow(hWnd);
In continuation With jose!, here is one more method to achieve same as Mr. Jose stated in his last post!:-
m_pMainWnd = new CMyFrameWnd;
::ShowWindow(m_pMainWnd-><code>GetSafeHwnd()</code>,m_nCmdShow);
::UpdateWindow(m_pMainWnd-><code>GetSafeHwnd()</code>);
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
wonderful && excellent! I catch it! Thank you very much!
And Thank you : Christian Graus,Jose Lamas Rios ,ThatsAlok
shanzy
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
