C / C++ / MFC

Re: Help with progress controls

18-Nov-02 15:28

Ah... Every installer progress control I have seen obviously did something like this:

how many files am I installing ?
add weight to files I know are bigger, so they represent 3 steps instead of 1 ( for arguments sake )
step every time a file has been copied.

Christian

No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002

Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002

Jason Henderson18-Nov-02 17:59

Jason Henderson

18-Nov-02 17:59

SteveBob wrote:
How do I constantly get the file size information I need?

If you are reading or writing these files, there are usually return values or reference parameters that will tell you the # of bytes written or read. Just add the number to a running total then divide by the total bytes and multiply by 100.

Jason Henderson
^{start page ; articles}
_{henderson is coming}
^{henderson is an opponent's worst nightmare}
^{* googlism *}

want suggestion in MFC.

User 988518-Nov-02 13:37

User 9885

18-Nov-02 13:37

I have an app, that receives data on multiple sockets on a thread pool and updates certain data objects. These data objects are accessed by MFC CFrameWnd derived windows to display them. I have seen that using critical sections in the data classes lead to many unfavourable inetractions causing deadlocks in MFC.

Is there an article/discussion on the procedures/guidelines that need to be followed in the design to prevent deadlocks in MFC apps when the data is mdified from another thread and the access to the data objects are protected using critical section or mutex?

Also, is it advisable to use a timer for periodic refresh of the windows OR send a message from the other thread to the window, asking it to refresh because of a data change? What are the procedures that can be used to prevent excessive re-painting due to large amounts of data arriving in a short period?

Any inputs are welcome.

Thomas

My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers

modified 29-Aug-18 21:01pm.

Re: want suggestion in MFC.

Gary R. Wheeler18-Nov-02 15:16

Gary R. Wheeler

18-Nov-02 15:16

Thomas George wrote:
Also, is it advisable to use a timer for periodic refresh of the windows OR send a message from the other thread to the window, asking it to refresh because of a data change? What are the procedures that can be used to prevent excessive re-painting due to large amounts of data arriving in a short period?

Funny you should ask that question. I'm working on an app right now with this very problem. I've tried both approaches. Using the timer works, in that it updates the screen regularly. Using the timer doesn't work when you've got a lot of data coming in, because WM_TIMER messages are low priority. As a result, the WM_TIMER doesn't happen in a timely fashion, so the display doesn't update as often as you'd like. Sending a message every 'N' data items has similar problems, in that it updates the display too much under high data rates. Fortunately, I can set this part of the problem aside for awhile, and let the back part of my brain figure out a solution.

Good luck. Sorry I couldn't be of any real help.

Software Zen: delete this;

Re: want suggestion in MFC.

Anonymous18-Nov-02 16:54

Anonymous

18-Nov-02 16:54

I had no problems with updating my GUI regulary depending on WM_TIMER message, but I believe you have if you say so.

In another project I created a thread that posted a custom message (not WM_TIMER) in regular distance to my GUI message queue... my GUI then updates the display regular.

Help: Performance Counter (PerfLib) 8-Byte Alignment Warning (Event ID 1016)

Gaul18-Nov-02 13:32

Gaul

18-Nov-02 13:32

I am getting the warning that the performance counter DLL is not aligned on an 8-byte boundary. I originally thought the warning was being caused by our code, but even the Microsoft sample codes, ScribbleMouse and HWInputMon written by Jeffrey Richter (MSJ Aug 1998), are giving the same warnings.

I checked the allocation size in the case of the ScribbleMouse, and at 160 bytes, seems to be properly aligned.

Does anyone know of a solution to this, or how to resolve the problem.

I have looked at the KB Q262335 referred to below, and have tried various options without luck.

HOWTO: Align Performance Data of a Performance Extension DLL on an 8-Byte Boundary

SUMMARY
When the performance data buffer returned by a performance extension DLL is not aligned on an 8-byte boundary, the performance library (PERFLIB) part of ADVAPI32.dll will report a warning 1016 to the Application Log in Event Viewer. This article explains how the developer of a performance extension DLL can align the performance data on an 8-byte boundary.

Gaul
http://www.gaulles.com

How do you prevent font size change while scaling DC?

Miguel Lopes18-Nov-02 13:13

Miguel Lopes

18-Nov-02 13:13

Hi. Im working on a project that has a print preview class that prints a lot of small text boxes. The problem is that using CDC::DrawText(...), the charaters size do not change linearly with zoom, but in small discrete "jumps", making the word wrap change the word disposition between lines. This is terrible, because what you see is not what you get(WUSI(N!!!!)WUG)!
Im zooming using MM_ISOTROPIC map mode.

Ive tried using a CRichEditCtrl to display text and the zoom works great, which makes me think i can make the text boxes work the same.

How do i crack this one?!?! Confused | :confused:

Thanks in advanced!

GUI Leaks

Matthew R. Miller18-Nov-02 12:25

Matthew R. Miller

18-Nov-02 12:25

When making custom draw controls, what “errors” would make the actual drawing take up system resources.

I have a custom graph that updates every second,, and it uses 2-4 % of the system, I think this is an error of some kind. I restore all of my GUI objects pens/brushes/etc.

Any help would be good.

"Best file compression around: DEL *.* = 100% compression."

<><><><><><><><><><><><><>
Matthew R. Miller
mattrmiller@computersmarts.net
www.computersmarts.net

Re: GUI Leaks

Christian Graus18-Nov-02 12:38

Re: Saving a tree control

18-Nov-02 12:38

If the amount used does not grow, then there is no leak, and I dunno without seeing the code if there's anything that is being done that is wasteful.

Christian

No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002

Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002

Saving a tree control

Russell Thorburn18-Nov-02 11:23

Russell Thorburn

18-Nov-02 11:23

I derived a class from CTreeView in order to implement drag and drop between trees. I also made it so I can add/delete/edit items in the tree. I need a way of saving the edited tree so I can load it up the next time I run my app.

Any suggestions? I don't want to have to parse through the tree and save/load that way.

Joaquín M López Muñoz18-Nov-02 11:30

Joaquín M López Muñoz

18-Nov-02 11:30

Look, for instance, Zafir Anjum's Serializing to / from a text file[^].

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

DirectX problem

Selevercin18-Nov-02 11:19

Selevercin

18-Nov-02 11:19

Hi,

I posted this message before, but maybe this time I can give a little more information.

I wrote a DirectX program using Marcio Ritter's tutorial. Sadly, it crashes everytime I run it. I have, however, narrowed it down to a line of code that is causing the problem. Here is the function, ProcessIdle()

void ProcessIdle()
{
	HRESULT hRet;
	BOOL bOK;

	// this line right here is causing problems...
	bOK = g_Brick.Draw(g_pDDSBack, 10, 10, 2, 2, 10,10);

    while( 1 )
    {
        hRet = g_pDDSFront->Flip(NULL, 0 );
        if( hRet == DD_OK )
        {
            break;
        }
        if( hRet == DDERR_SURFACELOST )
        {
            g_pDDSFront->Restore();
        }
        if( hRet != DDERR_WASSTILLDRAWING )
        {
            break;
        }
    }
}</code>

The while loop also causes problems if I remove the first problem line. I think that may be because I can only test that line when I remove the first problem line, and it needs that line to run.

Here is the function that the problem line calls:

BOOL CSurface::Draw(LPDIRECTDRAWSURFACE7 lpDest, int iDestX, int iDestY, int iSrcX, int iSrcY, int nWidth, int nHeight)
{
	RECT    rcRect;
    HRESULT    hRet;

    if(nWidth == 0)
        nWidth = m_Width;

    if(nHeight == 0)
        nHeight = m_Height;

    rcRect.left   = iSrcX;
    rcRect.top    = iSrcY;
    rcRect.right  = nWidth  + iSrcX;
    rcRect.bottom = nHeight + iSrcY;

    while(1)
    {
        if((int)m_ColorKey < 0)
        {
            hRet = lpDest->BltFast(iDestX, iDestY, m_pSurface, 
                                   &rcRect,  DDBLTFAST_NOCOLORKEY);
        }
        else
        {
            hRet = lpDest->BltFast(iDestX, iDestY, m_pSurface, 
                                   &rcRect,  DDBLTFAST_SRCCOLORKEY);
        }

        if(hRet == DD_OK)
            break;

        if(hRet == DDERR_SURFACELOST)
        {
            Restore();
        }
        else
        {
            if(hRet != DDERR_WASSTILLDRAWING)
                return FALSE;
        }
    }

    return TRUE;
}</code>

Thanks for your help! If you need to see the source code, PLEASE e-mail me for it! (nreveles@austin.rr.com)

If you have a problem with my spelling, just remember that's not my fault. I [as well as everyone
else who learned to spell after 1976] blame it on
Robert A. Kolpek for U.S. Patent 4,136,395.

Re: DirectX problem

Paul M Watt18-Nov-02 13:29

Paul M Watt

18-Nov-02 13:29

From looking at the code, the g_Brick object may not be initialized properly, or the g_pDDSBack surface. The g_Brick variable is an object that has been created, but have you actually created a surface to initialize this object.

The while loop may have problems because either the g_pDDSFront variable is not initialized and you are calling from it, or the g_pDDSBack variable is somehow used in the Flip function.

If you want to send me your code, zip up the source files and the project and send it to kilowatt@prodigy.net and I will be happy to look at it.

Good Luck

Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!

Subtle bug with static members...

Jamie Hale18-Nov-02 10:54

18-Nov-02 10:54

I think I have a very subtle bug here...

Here's the jist of it:

// First.h
class First {
	...
	static int i;
	...
};

// First.cpp
int First::i = 7;

// Second.h
class Second {
	...
	static int q;
	...
};

// Second.cpp
int Second::q = First::i;

I have a feeling that the order in which those statics get initialized is undefined (or at least compiler-specific), so Second::q might get 7 and might not.

Is this correct?

J

May the bear never have cause to eat you.

Christian Graus18-Nov-02 11:05

18-Nov-02 11:05

I dunno, but I would tend to do this instead:

const int STATICVALUE = 7;

int First::i = STATICVALUE;
int Second::q = STATICVALUE;

Christian

No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002

Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002

Jamie Hale18-Nov-02 11:10

18-Nov-02 11:10

Perhaps my example was poor. Smile | :)

Yes, that would solve the problem I posted. What I actually want to do is this:

class First {
	static char *szName;
};

char *First::szName = "First";

class Second {
	static char *szName;
};

char *Second::szName = "Second";


class User {
	static char *aszNames[];
};

char *User::aszNames[] = {First::szName, Second::szName};

The names are essentially constants, but the initialization order is still undefined. Frown | :(

J

May the bear never have cause to eat you.

Christian Graus19-Nov-02 10:08

19-Nov-02 10:08

The newsletter must be going out, I just got this. Got a ton of notifications inbetween tho Confused | :confused:

Christian

No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002

Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002

Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002

Jamie Hale18-Nov-02 11:05

Re: Subtle bug with static members... [corrected]

18-Nov-02 11:05

Once again, I found the answer to my own question. Unfortunarly, I was right. Thankfully I found it before it posed any major problems...

Here's a nice link[^] to an explanation and potential solutions.

J

May the bear never have cause to eat you.

Joaquín M López Muñoz18-Nov-02 11:06

Joaquín M López Muñoz

18-Nov-02 11:06

This is absolutely correct (I mean, it is pontentially broken as you suspected). In your particular case, chances are that you don't notice anything strange, as initialization of First::i can be done in compile time (i.e. the value 7 is directly stored in the executable). Try this for some more fun:

// First.h
class First {
	...
	static int i;
	static int j;
	...
};
// First.cpp
int First::i = 7;
int First::j = Second::q;
// Second.h
class Second {
	...
	static int q;
	static int r;
	...
};
// Second.cpp
int Second::q = First::i;
int Second::r = First::j;

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Re: Subtle bug with static members... [corrected]

Jamie Hale18-Nov-02 11:11