I am under the impression that a watchpoint's purpose is to stop the
execution of the program being debugged whenever the value of the
watched variable changes. This, of course, is very useful with global
variables, or those that can be modified in many places throughout the
code.

I have tried this:

1) Start the debugger by selecting "Step Into" or "Step Over"
2) Find the variable that I need to watch, double click to highlight
it
3) Select "Add Watch" from local menu.

The expected behavior is for the program counter to stop whenever that
variable is modified, but this is not happening.

What am I doing wrong?

TIA,

-RFH

MSVS 2005, Version 8 (C++), Professional Edition

Hi,

I've written a DLL which relies on another (3rd party) DLL. The (3rd
party) app which loads my DLL, is located in another folder than my DLL
and probably loads it by specifying the path explicitly. The consequence
is that, when loading my DLL, Windows doesn't find the 3rd party DLL
automatically if it is stored in the same folder as my DLL. Instead the
3rd party DLL must be stored in the system32 folder.

Is there any way to tell Windows to first search for the 3rd party DLL
in the folder that my DLL is stored in? Can it be done with a manifest file?

Here's the folder structure I'm talking of:
C:\Program Files\Mozilla Thunderbird\thunderbird.exe
-> this is the 3rd party app
%%APPDATA%%\Thunderbird\Profiles\xuatsjj6.default\extensions\IMAPSafe\platform\WINNT_x86-msvc\components\IMAPSafeIMAPProxy.dll
-> this is my DLL
%%APPDATA%%\Thunderbird\Profiles\xuatsjj6.default\extensions\IMAPSafe\platform\WINNT_x86-msvc\components\cl32.dll
-> this is the 3rd party DLL

Hi,

I have a windows MDI program that draws some shapes that can
be saved into a file and read from that file.
The save seems to work with the WriteFile function, but for some
reason
the ReadFile function fails. These WriteFile/ReadFile are win32 api
functions.

I'll post both, the read and write function codes here so you can take
a
look at and perhaps see what the problem is.

---- code WriteFile start -----
BOOL WriteDrzFile(HWND hwnd, LPSTR pstrFile, PTHINGZDATA pThingzData)
{
HANDLE theFile;
BOOL bSuccess = FALSE;

DWORD dwSize;

char szTmp[255], szOut[255];
PtrThingzShapeSave thingzSaveData;

Hi Folks:

I have an MDI application that I'm making behave in a way an
MDI app was never intended to behave.

What could go wrong? :)

I could fill a page describing what I'm trying to do, but it
breaks down to building my own desktop inside of an MDI frame.
This means maintaining multiple parent-modal child relationships,
let's call them tasks. As is described in Google's archives for
this group, having a child disable it's parent is a common
method to maintain a parent-modal child relationship among the
children of an MDI frame.

A stack is built with the handles of each MDI child and
DeferWindowPos() is used to place the window to be active
and in focus at the top of the Z order. I use
EnableWindow(, TRUE) followed immediately by SetFocus() to
bring the MDI child into focus.

This works almost perfectly. But in certain, repeatable,
situations the window is enabled, but doesn't receive focus,
with the darker blue frame.