C / C++ / MFC

10-Jun-01 22:37

Where do you want to add the date ? In your about box ? The menu bar ?

GetSystemTime will give you the info you need, COleDateTime has a constructor that takes this info if you *need* this object for some other reason and what you do with it depends on what you want to do with it.

Christian

#include "std_disclaimer.h"

People who love sausage and respect the law should never watch either one being made.

The things that come to those who wait are usually the things left by those who got there first.

Re: begginner with MFC

Drake Elsari11-Jun-01 3:20

Drake Elsari

11-Jun-01 3:20

Well, thats kinda what I meant, it's close. But I really meant how to draw that stuff on there. And I don't wanna just use the windows frame components I wanna make my own version of them and then paint them on the Frame window.

Re: begginner with MFC

Christian Graus11-Jun-01 11:03

why the scrollbar doesn't work for a dialog window?

11-Jun-01 11:03

Ah - so you're not really that interested in the date, you want to draw your own window frame ?

WM_NCPAINT is the message you want to catch - it indicates you want to paint the non-client area of a window (i.e. the frame).

Christian

#include "std_disclaimer.h"

People who love sausage and respect the law should never watch either one being made.

The things that come to those who wait are usually the things left by those who got there first.

10-Jun-01 15:22

Hi,

I need a dialog window to display controls in more than
one screen. I check the scrollbar in the property of the dialog.
But when the program run, I still only can get one screen display
no matter how I move the scroobar. What's the reason for the problem?

Thanks for your help!

Tom

Re: why the scrollbar doesn't work for a dialog window?

Stan Shannon10-Jun-01 15:56

Stan Shannon

10-Jun-01 15:56

Are you saying you actually want to move the other controls within the dialog box by means of the scroll bar?

Switching to a particular record in a database

mArkcpp10-Jun-01 12:25

mArkcpp

10-Jun-01 12:25

Hello. I am using ODBC to connect to an access database. I have a treectrl in my application that lists all of the records from a particular field in the database. I need to be able to click an item in the treeview and switch to the corresponding record of the item clicked. I already know how to get the item clicked in the treeview, but now I can't figure out how to switch to the record that was clicked in the treeview. I'm also not sure I am going about it the best way. Right now I am attempting to use a filter, which I thought was easy, but I can't get it working for the life of me. I'm sure I'm missing something easy. Could someone lend some help. Thanks in advance. Here is some of the code from the OnSelchangedTree class which gets the item clicked in the treeview. (Should my filter code be somewhere else?)

m_pSet->m_TestParam=text; // the item clicked in treeview
m_pSet->m_strFilter = "[Test] = ?";
m_pSet->Requery();

My program compiles, but when I click on an item in the treeview it gives me a popup message saying "Too few parameters : Expected 2".

Thanks for any help.

mArk

Re: Switching to a particular record in a database

Tim Deveaux10-Jun-01 14:42

Tim Deveaux

10-Jun-01 14:42

If I remember correctly changing the where (filter) or order by (sort) clause in an ODBC recorset makes the Requery equivalent to a Close and Open with a new sql query string, so you can try that route without losing anything. If you've used the MFC wizard for the class, you're limited to a SELECT * or whatever's set up in the RFX stuff (i.e. same cols as in DoFieldExchange) but you can override GetDefaultSQL to fiddle a bit with WHERE clauses and the like.

But I'm not sure the requery is what you want in this context. You want to make the record current and display the data.

Hmmm - you might want to look at the DDX_FieldLBIndex function - no experience with it myself, just came on it in the MSDN. If there was something of this sort for a tree you'd be set, I think - or maybe a list is a better paradigm.

With the tree, worst case, you'd end up cycling through records till you found the one the user clicked on wanted then you'd display it. This is what the DDX_FieldLBIndex saves you from, I think, unless you want to cache all the records before displaying the tree.

later...
Oops - now that I think of it, you should be able to cache the record number and Move to it - maybe as itemdata in the tree. Might need code to check in case another user deleted it - see IsDeleted.

Re: Switching to a particular record in a database

Masaaki Onishi10-Jun-01 14:54

Masaaki Onishi

10-Jun-01 14:54

Hello, the codegurus around the world.;)

As long as you search the string, you need 'search_word' format.
However, you search the number, you don't need ' '.
Also, this rule may depend on the database type.

If you use Access database, you need this.
The below code is used for Access Database.

CString msg, strSQL;
long id;

m_pSet->Close();
int result = keyword.Compare("[ID]");

if(!result) {
    id = atol(m_searchword);
}
    // search for the number;
if(status){
if(!result) strSQL.Format("%s = %d", keyword, id);
    // search for the string
else
strSQL = keyword+ " = '" + m_searchword + "'";
msg = "No matching records to "+m_searchword;
}
    else {
if(!result)
    // another supports by Access Database "Like" flag
strSQL.Format("%s Like '%d%s'", keyword, id, "*");
else
    strSQL = keyword + " Like '" + m_searchword + "*'";

msg = "No matching records begining by " + m_searchword;
}

    m_pSet->m_strFilter = strSQL;
m_pSet->Open();

Have a nice day!

-Masaaki Onishi-

Re: Switching to a particular record in a database

mArkcpp11-Jun-01 14:23

mArkcpp

11-Jun-01 14:23

Thanks. I got it working using the code I already had actually. My problem was that I was returning zero records because my hItem was of the type char whereas my access database record was of the type CString. So, I took care of that and my code worked!! : )

However, now when I Requery, the arrows at the top of the program to move to the next or previous record remain accessible for clicking even though there is only one record that matches the filter. When it is clicked, then all the buttons are "greyed" out. Any ideas? Thanks again.

mArk

WM_PAINT in View

BryanBHU10-Jun-01 9:00

10-Jun-01 9:00

I've been reading pages and pages of the old posts here, and it seems people are using OnPaint to do the drawing at times.

In Class Wizard (VC++5), when I select WM_PAINT message the info box explicitely says:

"Indicates a window frame needs repainting (do NOT use for views)

So this means, they don't want us to override it in View class? For this reason, I have only used OnDraw so far to draw EVERYTHING. Am I missing something here? Whats the difference between OnPaint and OnDraw?? Thank you.

Michael Dunn10-Jun-01 9:56

Michael Dunn

10-Jun-01 9:56

OnPaint is a WM_PAINT handler. OnDraw is an MFC construct that lets you use the same code for drawing on the screen and printing. Notice how OnDraw has a CDC* paramter - MFC sets up the device context correctly for you and passes that to OnDraw.

So yes, OnDraw is the right function to use.

--Mike--
http://home.inreach.com/mdunn/
#include "buffy_sig"

BryanBHU10-Jun-01 10:21

10-Jun-01 10:21

ahh I see. Thanks, that's clear. So I just ignore WM_PAINT OnPaint then, and get on with OnDraw. It's puzzling though, when people talk about OnPaint... They might just as well say OnDraw in the first place if thats what they're referring to by OnPaint or WM_PAINT...

Thanks again.

Christian Graus10-Jun-01 12:44

10-Jun-01 12:44

If you use OnPaint, you can select when the device context is called, by moving the call to CPaintDC. This is useful because there is no point in double buffering if you draw to your memDC and the screen has been blanked by CPaintDC - you still get flicker.

The alternative is to do your double buffering in OnPrepareDC, which is called prior to OnDraw and the DC from OnPrepareDC is passed to OnDraw. However, as a lot of examples use OnPaint, it's hardly surprising that a lot of people use it as well ( myself included from time to time ).

Christian

#include "std_disclaimer.h"

People who love sausage and respect the law should never watch either one being made.

The things that come to those who wait are usually the things left by those who got there first.

BryanBHU10-Jun-01 13:59

10-Jun-01 13:59

So, there's no point in double buffering in OnDraw?? What I've done so far is to use memDC to do rendering then BitBlt to pDC, and also override WM_ERASEBKGRND to prevent erasure of background.

So what I should do is to use OnPaint instead, don't override OnEraseBkgrnd, and draw using memDC (backbuffer) then at the VERY last minute I call CPaintDC (causing screen blank) to get dc for BitBlt?

Jonathon Lockett10-Jun-01 16:39

Jonathon Lockett

10-Jun-01 16:39

I'd use OnPrepareDC, which passes to OnDraw, but caling PaintDC at the last possible moment in OnPaint will give the same result. Of course, if you've overridden OnEraseBackground then all should be fine anyhow, but it's less messy to let OnErase do it's job ( or your version of it's job, for example to draw a texured background ) and set the rest up accordingly.

Jonathon

BryanBHU10-Jun-01 16:48

10-Jun-01 16:48

I see - I never knew those various methods.

I hated messing with OnEraseBkgrnd so I guess I'll do that OnPrepareDC way. That sounds a lot cleaner and more "decent" way to do it.

Thanks!

Christian Graus11-Jun-01 0:33

11-Jun-01 0:33

I personally use OnErase to only draw to the area not covered by my bitmap ( when someone maximises ) and use OnPrepareDC to draw the bitmap. I don't think there is one *right* way of doing things ( hence the variety of methods available ), but if just using OnPRepareDC suits your current application it is certainly the easiest way to go.

Christian

#include "std_disclaimer.h"

People who love sausage and respect the law should never watch either one being made.

The things that come to those who wait are usually the things left by those who got there first.

Tomasz Sowinski11-Jun-01 3:01

Tomasz Sowinski

11-Jun-01 3:01

There's one drawback associated with painting in OnPrepareDC. If your view is derived from CScrollView, you call OnPrepareDC before converting from device to logical coords, and vice versa. Complex drawing code may slow things down - DP/LP conversion is usually done during mouse-related events, when user draws the selection rectange for example.

Tomasz Sowinski -- http://www.shooltz.com.pl

BryanBHU11-Jun-01 8:11

11-Jun-01 8:11

Well... I guess I'll go back to the good ole OnDraw & Erase combo, that might be best after all.

>I'd say this is the right way. I'm using it without any problems.
>Do you have any special requirements?

There's a frame along the client, which I draw nearly always... It just occured to me, I could draw that in OnErase for "erase" purposes.... what an idea. Kill 2 birds with 1 stone, Why didn't I think of that before?