C / C++ / MFC

Stephen Hewitt13-May-10 14:01

13-May-10 14:01

I'm not sure what you're asking exactly, but there is a little problem with your code. It's probably not a good idea to manipulate the registry in every sizing event. Just record the size when the window is destroyed and read-and-set when the window is created.

Steve

Fareed Rizkalla13-May-10 15:45

Fareed Rizkalla

13-May-10 15:45

The problem isn't with the saving, can you imagine when you close and reopen the application.
The window changes size on it's own, although I haven't modified or changed the window coordinates in anyway. If not dimensions or position! Unsure | :~

Stephen Hewitt13-May-10 15:51

13-May-10 15:51

Nevertheless, accessing the registry on every size event is an insane design.

Steve

Fareed Rizkalla13-May-10 16:09

Fareed Rizkalla

13-May-10 16:09

The user won't change the size of the window every moment, because the program is still buggy.
I was trying to maintain the last state, to ensure the crashes didn't harm much of the program.
Smile | :)

Stephen Hewitt13-May-10 16:54

13-May-10 16:54

Firstly, don't access the registry in these notifications: it's crazy and will slow down your application's responsiveness. If your going to do something, don't stuff it up before you start!

Secondly, WM_SIZE and WM_MOVE events will be sent during the creation of the window, even without any user interaction. This is what most people would expect (think of it this way: the windows is being moved and sized by the system when it's created).

Finally you don't seem to be doing any coordinate mapping (see ClientToScreen[^]), although I admit you haven't posted the code which restores the window position and size at startup.

Steve

norish13-May-10 19:45

norish

13-May-10 19:45

I suggest a general logging technique like below;

case WM_CREATE[
{
    RECT rect;
    GetWindowRect(hWnd, &rect);
    write_log("WM_CREATE: %d, %d, %d, %d\n",
        rect.left, rect.top, rect.right, rect.bottom);
    ... other codes ...
    return 0;
}
case WM_SIZE:
{
    write_log("WM_SIZE: %d, %d, %d, %d\n", 
        WCA.left, WCA.top, WCA.right, WCA.bottom);
    return 0;
}
break;
case WM_MOVE:
{
    write_log("WM_MOVE: %d, %d\n",
        LOWORD(lParam), HIWORD(lParam));
    return 0;
}

write_log() maybe like this;

void __cdecl write_log(const char* format, ...)
{
    va_list(args);
    va_start(args, format);
    FILE* fp = fopen("trace.log", "a");
    vfprintf(fp, format, args);
    fclose(fp);
}

You might be able to catch the point with the log file.

Asyncrhonous Multiple Processes [modified]

David Crow14-May-10 8:12

David Crow

14-May-10 8:12

Have you bothered to set breakpoints on the RegSetKeyValue() calls and use the debugger to see if the variables have the expected values? Anything short of that is a waste of time.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Man who follows car will be exhausted." - Confucius

Orion Star13-May-10 10:27

Orion Star

13-May-10 10:27

I am using Joseph M. Newcomer's WaitInfo
An Introduction to Processes: Asynchronous Process Notification[^]
to run multiple processes. I needed multiple WaitInfo because each time it will overwrite the hProcess info so I made WaitInfo into a vector

std::vector<WaitInfo> waiter

Next I have it

HANDLE hProcess = Launch(_T("notepad.exe")); //Launch = ShellExecuteEx

int idx = (int)waiter.size() + 1;
waiter.resize(idx);  // Increase vector size for the new process
waiter.at(idx-1).requestNotification(hProcess, this);

The code can launch 3 notepad without a problem.

However upon terminating either first two notepad it would crash. If I terminate the last one it would fine.

I traced it back to

::WaitForSingleObject(hProcess, INFINITE);
notifyee->PostMessage(UWM_PROCESS_TERMINATED, 0, (LPARAM)hProcess);

For the first two hProcess became 0xfeefee and the last process had the correct hProcess value.

I am unsure why the first two lost it's hProcess value. At the time of WaitForSingleObject their hProcess were correct. Since each WaitInfo has it's own vector so it shouldn't overwrite or clear the first two.

Well from the looks of it notifyee is gone as well. WTF | :WTF:

modified on Thursday, May 13, 2010 5:58 PM

Stephen Hewitt13-May-10 14:08

13-May-10 14:08

Orion Star wrote:
waiter.resize(idx); // Increase vector size for the new process
waiter.at(idx-1).requestNotification(hProcess, this);

Is WaitInfo copy constructible and assignable. Perhaps when the vector is reallocating it's storage and copying the old contents to the new buffer a problem is occurring. Test this by calling reserve on the vector to set the final size before adding and elements:

std::vector<WaitInfo> waiter;
waiter.reserve(10); // We're going to use 10 WaitInfos.
// Code the add stuff to the vector...

Steve

Orion Star13-May-10 15:37

Orion Star

13-May-10 15:37

Doesn't look like it

I tried

waiter.reserve(idx+1) and waiter.reserve(idx+10)

before I resize. Same problem

The thing is I checked waiter content, hProcess and notifyee, right after

waiter.at(idx-1).requestNotification(hProcess, this); 
HANDLE check = waiter.at(idx-1).GetHandle() // GetHandle() == return hProcess from waiter

and each time it's correct from my program side.

I just don't know why they are gone after the process ends

Stuart Dootson13-May-10 15:37

Stuart Dootson

13-May-10 15:37

That's fundamentally unsafe…when you call requestNotification, the WaitInfo class passes its address to the thread it creates, and uses that address. When you resize a vector, it's likely to move its content when it has to reallocate storage, invalidating the pointer that was passed to the thread.

You're probably better off using a std::list, as it doesn't move items when it is altered. It's also just as easy to use (you could use the insertion code I show for vector as well…):

std::list<WaitInfo> waiter;

HANDLE hProcess = Launch(_T("notepad.exe")); //Launch = ShellExecuteEx

waiter.push_back(WaitInfo());
waiter.back().requestNotification(hProcess, this);

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

CodeProject MVP for 2010 - who'd'a thunk it!