|
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.
|
|
|
|
|
Hi
I want to create a Russian dialog, I set the dialog resource language to Russian, but when I paste a Russian word into a static text all chars change to questuion mark!
(I've added Russian language to my Windows Languages)
I use Visual Studio 2003, MFC Project(Unicode) and Windows 2000 Professional.
What I must to do?
Thanks
-- modified at 6:42 Sunday 5th November, 2006
|
|
|
|
|
|
Your project must be either UNICODE or MBCS. Also you might want to check you are using a Russian compatible font to display the characters.
|
|
|
|
|
Project is Unicode and I used a Russian compatible font, but it does not work
|
|
|
|
|
Could you show us how you are setting the text to the control?
|
|
|
|
|
I'm not much of a mathematician, so hopefully somebody knows of an easy way to do what I want. Lets say we have a rectangle { 0,0,800,600 }, within that rectangle is another { 200, 200, 400, 300 }. How is it possible to calculate the position and size of the largest rectangle that can be created in the remaining space. In this case it would be { 0,300,800,600 }.
This example is very simple, I would actually have up to 10 smaller rectangles to compensate for. If you are wondering why, I want to calculate the best place to draw text in between the various child controls on a window.
|
|
|
|
|
In general there are four possible rectangles to consider, the upper one, the lower one, the left one and the right one. If the coordinates of the outer rectangle are (ol, ot)-(or, ob) (“o” for outer and “l”, “t”, r” & “b” for left, top, right and bottom, respectively) and the coordinated of the inner rectangle are (il, it)-(ir, ib) are the coordinates on the inner rectangle (“i” for inner) the four largest rectangles that fit in the remaining space are:
Top:
(ol, ot)-(or, it)
Bottom:
(ol, ib)-(or, ob)
Left:
(ol, ot)-(il, ob)
Right:
(ir, ot)-(or, ob)
All that remains is to calculate their areas and choose the biggest one.
[ADDED]
I just noticed you want many inner rectanges and not just one. This makes it harder. Obviously my method assumes just one.
Steve
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
