|
I actually understood what you meant with the .dsps, I do not understand what "calling" a dialog means, and what your error was.
Try this: include the header file where the GTDCommonControls are defined into your GTD c-file to make it known there.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
|
|
|
|
|
hi Rage,
I kept the Header file in that file. I have Already included the file that i want to Use.
But There is a Linker Error while linking.
Uday kiran
|
|
|
|
|
When using this code,i am getting folowwing error,what does it mean
<br />
strcpy (m_TQuote.m_Ask,Ask);<br />
strcpy(m_TQuote.m_Bid,Bid);<br />
strcpy(m_TQuote.m_DateTimeStamp,Timestamp);<br />
strcpy(m_TQuote.m_MarketName,Market);<br />
strcpy(m_TQuote.m_MarketNo,MarketNo);<br />
m_Set.Insert();<br />
m_Set.SetData();<br />
Error
: error C2664: 'strcpy' : cannot convert parameter 1 from 'union tagCY' to 'char *'
: error C2664: 'strcpy' : cannot convert parameter 1 from 'union tagCY' to 'char *'
No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
: error C2664: 'strcpy' : cannot convert parameter 1 from 'double' to 'char *'
There is no context in which this conversion is possible
: error C2664: 'strcpy' : cannot convert parameter 1 from 'union tagCY' to 'char *'
|
|
|
|
|
It means that you are not passing in a char*. Can you please show your declaration of m_TQuote.
|
|
|
|
|
What is m_TQuote.. can you give its definition...
check the first parameters of all the strcpy is char*
Do your Duty and Don't expect the Result
|
|
|
|
|
abrakadbra wrote: : error C2664: 'strcpy' : cannot convert parameter 1 from 'union tagCY' to 'char *'
: error C2664: 'strcpy' : cannot convert parameter 1 from 'union tagCY' to 'char *'
No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
: error C2664: 'strcpy' : cannot convert parameter 1 from 'double' to 'char *'
There is no context in which this conversion is possible
: error C2664: 'strcpy' : cannot convert parameter 1 from 'union tagCY' to 'char *'
Welcome back, are you still stuck with the same[^] issue!!
|
|
|
|
|
Your parameters are wrong
char *strcpy( char *strDestination, const char *strSource );
double to char* isnt true
|
|
|
|
|
You need to indicate what statement is in error (saying there is a C2664 error on some line is not much help), as well as what m_TQuote.m_Ask is.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
|
I get error messages for OpenPrinter and ClosePrinter:
- identifier not found
- is not a member of 'operator' 'global namespace'
Please help!
|
|
|
|
|
Your error means there is a problem with your code, but since you have haven't shown us any, it's going to be a little difficult for anybody here to help you.
|
|
|
|
|
Can you show snippet code but see here[^]
|
|
|
|
|
I am having a small problem with an owner drawn status bar pane and the resizing size grip that is located in the bottom corner of my main window. Normally when one resizes a window and makes it smaller to the point where the first message pane in the status bar can no longer be made any smaller the size grip will be drawn over top of the panes under it, erasing the pane so that it does not show through the size grip. But with my owner drawn pane the erasing does not happen, the size grip is simply drawn over it. You can see what I mean by looking at the picture I posted here[^].
The picture consists of three images, the top is a normal status bar with the size grip on the right. The middle one shows how the size grip draws over a pane, erasing the pane so it does not show through the size grip. The bottom is what I am getting with my owner drawn pane. I want my custom pane to react to the size grip the same way the default panes do.
Here is the relevant (I hope) code for my custom pane:
BOOL CMyStatusBar::Create(CWnd *pParent)
{
BOOL ret = CStatusBar::CreateEx(pParent, SBARS_SIZEGRIP);
[snipped]
return ret;
}
void CMyStatusBar::DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct)
{
if (2 == lpDrawItemStruct->itemID)
{
HDC hdc = lpDrawItemStruct->hDC;
CRect rc(lpDrawItemStruct->rcItem);
[snipped]
TRACE(_T("rc.Width() is %d\n"), rc.Width());
BitBlt(hdc, rc.left, rc.top, rc.Width(), rc.Height(), BackGroundDC, 0, 0, SRCCOPY);
}
}The problem is that the width of the rectangle supplied to DrawItem() extends right up to the right hand border of the status bar. It is not truncated because of the presence of the size grip.
Is there something I am missing? Any ideas or help would be appreciated.
Thanks
[edit]
I should mention I am using MFC8.0 on XP SP2 for this.
[/edit]Last modified: 22mins after originally posted --
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
PJ Arends wrote: BOOL CMyStatusBar::Create(CWnd *pParent){ BOOL ret = CStatusBar::CreateEx(pParent, SBARS_SIZEGRIP); // skipping SBARS_SIZEGRIP makes no diff [snipped] return ret;}
You can remove the sizegrip style in PreCreateWindow.
|
|
|
|
|
The DC you are drawing to is the DC for the whole window, in this case the status bar. So basically anything you draw to it is going to overwrite anything beneath it. What you need to do is calculate the space for each item you are drawing, and make sure it only draws into that rect. My guess is that you need to subtract from the rectangle provided to DrawItem() the width of the gripper, leaving space to draw the gripper. From the picture I see you also have a progress bar, you should also resize that otherwise it is going to get clipped also.
|
|
|
|
|
waldermort wrote: My guess is that you need to subtract from the rectangle provided to DrawItem() the width of the gripper, leaving space to draw the gripper.
Yeah, I figured I could do something like that, but then I need to know if the gripper is over my pane, and what size is the gripper so I know how much to take off. I could calculate it based on what it is on my system, but a differnt OS might have a different sized gripper.
I was hoping someone could tell me what flag I missed when creating the statusbar control so that the rect passed to the DrawItem function would already take the size grip into consideration. Would make things a lot easier.
waldermort wrote: From the picture I see you also have a progress bar, you should also resize that otherwise it is going to get clipped also.
It's not really a progress bar. It is actually just a bitmap that I use to simulate a progress bar control. The problem is that I want it clipped, but that is just not happening right now.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
I have write a ftp client , multi-thread to download at the same time.
In every thread, the client send the "REST 100\r\n" command to the ftp server, and response ok. But, the server always return the data from the file header. So, it cannot get the correct data.
Could you help me?
Thanks very much!
Royal (Email: Royal@jiamasoft.com ; MSN: CatchException@hotmail.com )
|
|
|
|
|
Does your FTP server support the REST command? Not all servers do...
Else, are you sending the REST cmd immediately before a data transfer command (RETR or STOR)?
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
I have try these steps:
(1) -> Logon -> Type I ->PASV -> REST -> RETR ->
(2) -> Logon -> Type I ->REST -> PASV -> RETR ->
When send the REST command to the ftp server ,
return 350 , it's ok.
|
|
|
|
|
Using VS2005...
[EDIT #2]
Nevermind - caused by stupid programmer tricks...
[/EDIT #2]
I have a non-MFC DLL that checks _MSC_VER and _MFC_VER to conditionally compile the code. This seems to work just fine.
HOWEVER, I also have a MFC app that uses the same code, but the compiler seems to ignore those two preprocessor definitions. Here's the code in question:
#ifndef _MFC_VER
#include <windows.h>
#include <stdio.h>
#include <crtdbg.h>
#include <tchar.h>
#if _MSC_VER < 1400
#define TRACE ((void)0)
#else
#define TRACE ((void)__noop)
#endif
#pragma message(" compiling for Win32")
#else
#include "stdafx.h"
#pragma message(" compiling for MFC")
#endif
In the MFC app, the block contained within #ifndef _MFC_VER is active instead of the #else block. As an experiment, I inserted #define _MFC_VER 8.00 above the code you see there, and the #else block became active. Despite the fact that the first block is inactive, the compiler still appears to process the code within the #ifndef _MFC_VER block, generating errors about unexpected endif's and warnings about duplicate TRACE macro definitions.
Does anyone know how to resolve this?
[EDIT]
I moved the following code out of the outermost #ifdef, and that resolved the duplicate definition warning regarding the TRACE macro:
#if _MSC_VER < 1400
#define TRACE ((void)0)
#else
#define TRACE ((void)__noop)
#endif
However, the compiler still doesn't seem to see the _MFC_VER macro at all, and the compiler is still puking out errors regarding unexpected #endif's...
-- modified at 10:25 Sunday 5th November, 2006
-- modified at 10:32 Sunday 5th November, 2006
-- modified at 10:33 Sunday 5th November, 2006
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Are you confusing _MFC_VER and _MSC_VER? 
|
|
|
|
|
Ummmm, nooooo. I'm using both.
In any case, one problem was that I had the stdafx include INSIDE the #ifdef. This prevented the definition of _MFC_VER in time to be evaluated, so it appeared to be ignored, when if fact, it wasn't defined in time.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
PrabhuDev wrote: is it possible to make a floating control bar to behave like a modal dialog?
Yes. Subclass the control bar and provide a Message loop. Message loop here means the one like in WinMain. This should make your control bar modal.
|
|
|
|
|
PrabhuDev wrote: can u please give me more details regarding this?
Thanks and regards,
Sure. Look up this article by Nish. You will understand I meant.
In this article he talks about how to create modal windows. The same technique will apply to control bars too.
Modal Inputbox[^]
|
|
|
|
|
PrabhuDev wrote: EnableWindow(FALSE);
ShowControlBar(&g_DemoBar, TRUE, FALSE);
MSG msg;
while (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
EnableWindow(TRUE);
Why are you writing this message loop here and why are you calling EnableWindow(FALSE).
You should write the message loop inside the ShowControlBar function. The message loop should come just after the Control bar is shown. There is no point in writing the message loop here.
There is no need to call EnableWindow anywhere. Look at what nishant has done.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
