|
the code is:
COleDateTime time2;
time2.SetDateTime(2005,2,2,10,54,12);
CString str = time2.Format(_T("%H:%M:%S %B %d, %Y"));
when the function returns,the error is:
" module:
file:i386\chkesp.c
line:42
the value of esp was not properly saved across a functin cail. this is usually
a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention "
But in release mode ,it is all right!
why?How can I solve the problem,that is "convert a date type variant to string"?
Thanks!
|
|
|
|
|
stick04 wrote:
when the function returns,the error is:
" module:
file:i386\chkesp.c
line:42
Have you stepped into the Format() method to see what statement produces the error?
stick04 wrote:
But in release mode ,it is all right!
Have you compared compiler options between debug and release mode?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Hi!
I have a problem with GDI.
I want draw a rectangle to memDC, then rotate it, last draw it to Screen. But when I draw it to memDC, it's single color.
code (draw it to memDC)
CDC DC;
DC.CreateCompatibleDC(pDC);
CBitmap bmTempBitmap;
bmTempBitmap.CreateCompatibleBitmap(&DC1,1024,768);
DC.SelectObject(bmTempBitmap);
CBrush brush;
brush.CreateSolidBrush(RGB(100,100,100));
CBrush* pOldBrush = (CBrush*)pDC->SelectObject(&brush);
CPen* pOldPen = (CPen*)pDC->SelectStockObject(NULL_PEN);
DC.Rectangle(&rcObj);
.... Rotate Rectangle....... copy to pDC, then write to screen.
Help me! Thank you very much.
|
|
|
|
|
Why would it be anything but single color ? GDI+ will allow you to draw bitmaps with textures, etc.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
Hello!
What is your 'rcObj'
it maybe a CRect object so you must send just itself to Rectangle function NOT a pointer, but if it is a RECT structure, well I didn't find any other special problem!!
|
|
|
|
|
 What do you mean, single color? Once you have draw it, in a single color (or any other way), then it is drawn. Whether you rotate it of not, afterward should make no difference.
Having said that, I think you need to dig a little deeper. I wrote an article that rotates a bitmap (and so have other members), it's either CDibData or CBitmapEx (I think!). I hope I gave enough comments, so that every one can see how it is supposed to work.
Good Luck!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Remember that creating a bitmap compatible to a memory DC is always monochrome. You have to create the bitmap compatible to a real DC. So in the CreateCompatibleBitmap() call, use pDC rather than &DC to make a colour bitmap.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi guys,
Im trying to develop an application that takes in a video image and derives a bunch of information from it. The problem is that there is ALOT of info to be displayed and I want to be able to make the interface extensible and add/remove "Dialog bars" from it that have controls in them such as CEdits, combos etc.
I started out with a dialog based application, then went to an SDI for its support of dockable Dialog bars, but now Im running into the issue that I can handle events for the controls, but I cant setup variables to control the data in them. i.e. I setup a message map but I get assertion issue when I try and use UpdateData(), if I use it in a global context in the mainfrm then I get an error. Now if I specify the dialogbox that has the Edit control in it I want to update i.e. m_wndViewTrans.UpdateData() then it does nothing with no error.
Specifically here are some code snippets:
From MainFrm.H:
/////////////////////////////////////////////////////////////////////////////
// CMainFrame
IMPLEMENT_DYNCREATE(CMainFrame, CFrameWnd)
void CMainFrame::DoDataExchange(CDataExchange* pDX)
{
CFrameWnd::DoDataExchange(pDX);
//{{AFX_DATA_MAP(ViewTrans)
DDX_Text(pDX, IDC_00, m_Edit00);
//Where IDC_00 is a edit box in a dialog resource(IDD_ViewTrans).
//}}AFX_DATA_MAP
}
In the OnCreate():
if(!m_wndViewTrans.Create(this,
IDD_ViewTrans,
CBRS_LEFT | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY,
IDD_ViewTrans) )
{
TRACE0(_T("Failed to create the toolbox\n"));
return -1;
}
Then a button on another toolbar is clicked causing the Edit box to be updated. The message map is omitted, trust me it works.
void CMainFrame::OnCalibPos()
{
m_Edit00 = 5.0;
m_wndViewTrans.UpdateData(FALSE);
}
From MainFrm.H
class CMainFrame : public CFrameWnd
{
protected: // create from serialization only
CMainFrame();
DECLARE_DYNCREATE(CMainFrame)
// Attributes
public:
// Operations
public:
// Dialog Data
//{{AFX_DATA(ViewTrans)
enum { IDD = IDD_ViewTrans };
//CComboBox m_Combo;
double m_Edit00;
and the rest...
PLEASE TELL ME WHAT I AM DOING WRONG... is what Im trying to do impossible? It builds with no errors, but it does nothing.
ALSO if anyone has any other ways to be able to create a bunch of modeless dialogs that can be docked and have message maps I would be greatly appreciated.
FURTHERMORE, if what I appear to be doing is complete garbage you are probabaly right, this is only my second MFC app.
Cheers, and thanks,
Will.
|
|
|
|
|
This is very confusing and not specific enough!
The assersions can be eliminated by testing the value that caused the assertion before calling the function (how you handle that is up to you).
If you are dealing with still images of the video data then you may be able to use CxImage (at CP), which converts the supported images to bitmap images (limits the image data you can manipulate, but only one dialog required).
I'm not sure if this helped, but it's better than nothing.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Hey there...
Hoping someone might be able to shed some light on an issue I am having while resizing windows. I've been banging my head against the wall for a week now and quite frankly, am out of ideas.
The main concept of what I am doing: I have a main window and three child windows. I essentially need to redraw the children over various parts of the main window. I do this during the main window's WM_SIZE.
ChildA and ChildB are drawn at start up and work perfectly, no issues. I calculate client_x and client_y from the lParam variable as normal. The problem is with ChildC which can be called at any point during run time. When it is invoked, it is loaded as the others are. ChildB redraws its bottom to be roughly half of the client height and ChildC draws its top at ChildB.bottom and its ChildC.bottom equal to client_y - status_bar.height
(these aren't real variables, just trying to be clear.
ChildA.bottom is ALSO equal to client_y - status_bar.height, again this looks perfect.
Looking with a debugger, both ChildA and ChildC have the same bottom value (447 in most cases). The thing is, ChildC ignores this value and draws well beyond the client area. I have to set it's bottom to be client_y - status_bar.height - 400 before I can even see the bottom of the window ???
I've compared window settings between all the children 100 times or more and am convinced they are all identicle (save for the controls they have).
Has anybody ever seen behaviour like this before? Or have any idea what it is I may be doing wrong?
I typically use MoveWindow(...) during the WM_SIZE call, but have experimented with SetWindowPosition(...) just to see if it would help.
I am coding with VC++ 7.1
thanks for any help/advice that you can offer.
Dave
|
|
|
|
|
It seems to me that ChildC is not being created as a child of the parent window that is controlling ChildA and ChildB. It might instead be a child of the desktop, and this could explain the '-400' you offset to modify its position. Double check the parenting for ChildC and see if that solves your problem.
|
|
|
|
|
Hi Blake and thanks for replying.
I double checked the parentage as you suggested. All three children are created in the WinProc(...) callback and all three use the same variable for parent (arg 1: HWND hWnd). Because I wrapped the creation process in a seperate function for each, I took the time to trace the process with the debugger so that I could actually eyeball the value of the handle, and it is indeed the same parent.
Another "strangeness I noticed last night while poking around at this issue: if I draw ChildA down to client_y, the two positions meet and form a nice 2px wide grey line (looks docked in other words). If I manage to get ChildC drawn to the same position, that 2px line forms, but it turns black instead of staying grey. I just don't understand the differnt behavior.
just to make sure the dialogs are being created the same, I opened up the *.rc and eyeballed the script:
ChildA:
DLG_TREE DIALOGEX 0, 0, 173, 154
STYLE DS_SETFONT | DS_FIXEDSYS | DS_CONTROL | WS_CHILD | WS_VISIBLE |
WS_CLIPSIBLINGS | WS_THICKFRAME
EXSTYLE WS_EX_TRANSPARENT | WS_EX_STATICEDGE
ChildB:
DLG_RECIPELIST DIALOGEX 0, 0, 301, 159
STYLE DS_SETFONT | DS_FIXEDSYS | DS_CONTROL | WS_CHILD | WS_VISIBLE |
WS_CLIPSIBLINGS | WS_THICKFRAME
EXSTYLE WS_EX_TRANSPARENT | WS_EX_STATICEDGE
ChildC:
DLG_RECVIEW DIALOGEX 0, 0, 331, 151
STYLE DS_SETFONT | DS_FIXEDSYS | DS_CONTROL | WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS |
WS_THICKFRAME
EXSTYLE WS_EX_TRANSPARENT | WS_EX_STATICEDGE
I'm completely confused. The only other thing I can think of is to try creating the window at the time that the other two are created ??? I fail to see how that would help though... but I've given up on logic at this point and am happily grasping at straws 
thanks for the input!
Dave
|
|
|
|
|
One more straw to grasp at.
I am not EXACTLY sure what the consequences of 'clipping a sibling' are. But suppose they accidentally overlap, even by one pixel. So, try perhaps removing the WS_CLIPSIBLINGS, just for grins, and see if that solves the problem. Maybe 'C' overlaps just a tad, and since it is clipped, it does not get draw messages, or some other bizarre side effect you did not anticipate. Just an idea, anyway.
|
|
|
|
|
Blake...
That was it I turned off the clipping for all three and it looks perfect and behaves as expected now.
Thanks so much for the help, after a week of that nonsense I'm tickled pink to see things line up
Thanks again
Dave
|
|
|
|
|
I can't figure out why the main menu component is not available on my dialog editor. It is grayed out along with Picture and Text components.
Thanks
-md
|
|
|
|
|
Hi,
I'm trying to gather network statistics for various LANs connected to a computer (if the adapter is active, number of packets, packets per second, number of collisions, etc). I've searched quite a lot for a way to do this but haven't had much luck.
Any help? 
Thanks!
Cheers,
Bail Organa
|
|
|
|
|
Does this article help?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Hi,
Thanks for your reply!
Does it help? No, not really! That article deals with TCP statistics (and more). I need actual ethernet statistics (ie, one layer down, if I'm not mistaken) such as the number of packet collisions.
Cheers,
Bail Organa
|
|
|
|
|
TCP resides at the Transport layer. Does what you are after reside at the Network, Data Link, or Physical (doubtful) layer?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Hello,
My app draws its own array of lines with a CButton array inside the OnDraw() method. However, when resizing the window, the lines look good, except that the background of the previous CButton window positions is white (erased). Upon overloading the OnEraseBackground() method in the CButton class, I see that it’s called AFTER the lines are drawn in OnDraw(). How do I get the background erase method to execute before the lines are drawn? Or, how do I get the CButtons to be updated COMPLETELY before the lines are drawn (the code draws the lines after calling the CButton.MoveWindow() methods ).
thanks,
JennyP
|
|
|
|
|
Very Strange, the OnEraseBkgnd should always be called before OnDraw. Anyway, one possible solution would be to call ExcludeClipRect or ExcludeUpdateRgn in the OnDraw function so that any future drawing will not draw over what has already drawn.
Note: The above may lead to unusual drawing, if OnDraw is realy called before OnEraseBkgnd.
What I recommend is to see if you can reproduce the problem in a simple test program (the smaller the better). This will allow one of us to see how OnEraseBkgnd is being called first (or you to see how that is happening).
I have found that if you override the OnEraseBkgnd to return TRUE and override the OnDraw function, so that it calls ExcludeClipRect or ExcludeUpdateRgn to validate anything you have drawn, is a great way to elimenate any flicker.
If you find a solution please post it (or write and article [prefered]).
If what you describe is actualy happening, I feel for you. It's one of those things that makes us want to pound are head against the wall (very depressing).
Good Luck, and keep progamming!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Thanks for the reply! View class contains an array of CButtons, so the CButton’s Erase is being called after the View’s OnDraw() method which moves the CButtons (MoveWindow()). Please see my other reply to this thread for a more complete description (I don’t want to double-post).
Thanks!
JennyP
|
|
|
|
|
what's mean "with a CButton array",which class does th OnDraw() method belong to?
your friend:bobi
|
|
|
|
|
Thanks for the reply. The View class contains an array of CButtons that it creates upon init-dialog. Then, in the View’s OnDraw() method, these buttons are repositioned (MoveWindow()) based on the user’s resizing the overall view. After calling MoveWindow(), I draw a bunch of lines (dc->LineTo()).
When the app is running and the user resizes the view, the lines all have blank squares imprinted over them where the CButton(s) used to be (i.e., before they were moved with MoveWindow()).
When I insert debug TRACE()s, I see that the CButton’s OnEraseBackground method is temporally executed AFTER the View’s OnDraw() is completed. I suspect that the MoveWindow() simply puts a message in the queue for the CButtons to erase themselves. However, I want this operation to complete immediately before the lines are drawn.
Any suggestions?
Thanks!
JennyP
|
|
|
|
|
just to be sure I do this the right way ...
I have a vector of something and I want to sort it according to a criteria; so I define a class as the criteria, and I want to pass some context to it ( some additional global thingies )
typedef std::vector < something > vectorOfSomething_t;
vectorOfSomething_t myVector;
...
vectorOfSomething_t::iterator start = myVector.start();
vectorOfSomething_t::iterator end = myVector.end();
std::sort( start, end, myCriteriaFunctor );
...
class myCriteriaFunctor
{
public:
myCriteriaFunctor ( bool b, int i ): m_vp(vp), m_bSortOrder( b ), m_iSomeContext(i) {};
private:
bool m_bSortOrder;
int m_iSomeContext;
public:
bool operator() ( something& something1 , something& something2 ) const
{
bool bSmaller;
...
return bSmaller;
};
the question, is it kosher to pass data like that to a sort functor ?
It's working right now, and I just want to be sure ...
Thanks.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
