Problems with Windows Dialog Box-based GUI Software Design

[bsmith12556]

Hi,

I am having issues with developing a Win32 API-based C language GUI
application for Windows 2000/XP to test a custom PCI device/WDM device
driver I developed for Windows 2000/XP.
For this GUI application, I am using Visual C++ 2005 Express Edition +
Windows 2003 SP1 SDK, therefore, I am not using MFC.
The custom PCI device here is an FPGA-based bus master capable 32-bit
PCI device.
The WDM device driver I wrote can perform a bus master transfer using
a separate worker thread with IRP queuing and cancellation support.
The Win32 API-based C language GUI application is meant to test the
WDM device driver and the custom PCI device.
I finally finished writing the WDM device driver, but because I don't
have the GUI application ready yet, I am not able to test the WDM
device driver at this point. (Especially, I need to test I/O
cancellation I implemented with my WDM device driver.)
The GUI portion of application is supposed to be fairly simple,
however, that's where I got stuck.
Although I originally started playing around with software, and I am
now a digital hardware designer (I do FPGA designs with Verilog HDL
and VHDL.), but because I wanted to demo what I have developed on a
PC, I now have the need to learn how to write a WDM device driver and
C language Windows GUI application.
This is how I want the GUI of the application to look like.


Initial Screen:

The initial screen contains several test modes that is selectable by
clicking a radio button.
I am thinking of supporting at least 3 test modes.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will be grayed out here because there is not a screen to go
back to.
"Next" will cause a transition to test mode 1, test mode 2, or test
mode 3 screen based on the current radio button setting.
"Exit" will cause the GUI application to terminate.


Test Mode 1 Screen 1:

The user will arrive in this screen from initial screen if test mode 1
was selected in the initial screen.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to the initial screen.
"Next" will be grayed out here because there is not a screen to
advance to.
"Exit" will cause the GUI application to terminate.


Test Mode 2 Screen 1:

The user will arrive in this screen from initial screen if test mode 2
was selected in the initial screen.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to the initial screen.
"Next" will cause a transition to test mode 2 screen 2.
"Exit" will cause the GUI application to terminate.


Test Mode 2 Screen 2:

The user will arrive in this screen from test mode 2 screen 1.
The user can press a button on the center of the GUI that starts a
test.
The user can press another button that stops the test.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to test mode 2 screen 1.
"Next" will be grayed out here because there is not a screen to
advance to.
"Exit" will cause the GUI application to terminate.


Test Mode 3 Screen 1:

The user will arrive in this screen from initial screen if test mode 3
was selected in the initial screen.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to the initial screen.
"Next" will cause a transition to test mode 3 screen 2.
"Exit" will cause the GUI application to terminate.


Test Mode 3 Screen 2:

The user will arrive in this screen from test mode 3 screen 1.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to test mode 3 screen 1.
"Next" will cause a transition to test mode 3 screen 3.
"Exit" will cause the GUI application to terminate.


Test Mode 3 Screen 3:

The user will arrive in this screen from test mode 3 screen 2.
The user can press a button on the center of the GUI that starts a
test.
The user can press another button that stops the test.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to test mode 3 screen 2.
"Next" will be grayed out here because there is not a screen to
advance to.
"Exit" will cause the GUI application to terminate.




In my opinion, the way I am trying to get these screen
transitions to work is very similar to how application installation
programs like InstallSheild handle screen transitions.
In such a application installation program, there is usually an
introduction screen the user press "Next" button to advance.
In the next screen the user usually have to accept license agreement
to move to the next screen.
The user can also go back to the previous screen or exit the
application installation program.
I am sure now you got the idea what I am trying to accomplish.
The part I am really having problems right now is how I can implement
this in my software development environment.
To write a Win32 API-based C language GUI application for Windows 2000/
XP, I have purchased Charles Petzold's Programming Windows, 5th
Edition (It is a good book, but I feel like the book has to be
rewritten pretty soon because it was published almost 10 years
ago . . .), Jeffrey Richter Programming Applications for Microsoft
Windows, 4th Edition, and Jeffrey Richter and Christophe Nasarre's
Windows via C/C++. (This book is up to date, and contains information
about Windows Vista, but not too much about GUI issues.)
This is so far how much I have written for the GUI
application.
I read through the chapters in Charles Petzold's book related to
dialog boxes and resources.
I have read through information related to dialog boxes contained in
Platform SDK.
I also relied on a Win32 programming tutorial by winprog.org.
Initial version of the code I wrote contained a call to
RegisterWindow and CreateWindow API functions within WinMain, and
after that there is a message loop. (That's the way Charles Petzold's
book does it, and the way SDK's documentation presents the examples.)
The window procedure RegisterWindow API function registered then
handles various messages to decide what to do next.
I used DialogBox API function to move to the next screen. (i.e., Go
from initial screen to test mode 2 screen 1.)
But the problem I had with this approach was that the initial screen
was still on the screen. (I want initial screen to be completely
replaced with test mode 2 screen 1.)
For various reasons, I didn't like this previous approach, so
I decided to look into a different way to write the GUI code.
In the code samples of Windows via C/C++, the authors of the book has
a very simple WinMain, calls a DialogBox right away within WinMain,
and WinMain does not contain a message loop. (I personally don't like
this message loop business, so I prefer this approach.)
But I still have the problem of making transition from one screen to
another screen if I used DialogBox API function because the previous
screen is still on the computer screeen.
In both approaches, I decided not to use CreateDialog API
function because that creates a modeless dialog box which is not what
I want. (I did experiment with it, but I didn't like the results I
got.)
I guess if I were the summerize the issues I am having with, the
problem I am having is how do I transition from one dialog box to
another, and be able to go back and forth?
Going back to the application installation program example, I know
that those programs handle screen transitions without the issues I am
having with DialogBox API function, and that is what I am trying to do
with my GUI application.
I hope I described my situation with adequate details so that someone
who is much more familiar with Win32 API programming can give me clues
as to how I should proceed from here.
I decided to invest some time in writing this posting rather than
struggling to read various books because I cannot seem to find
examples related to what I am trying to do here.
Thank you very much for reading this farily long posting.


Sincerely,

Bob

 

[red floyd]

[GUI design, MFC, etc... redacted]

Did you have a question about the C++ language proper?

If not, it's OT there.

F/U set

 

[jason.cipriani]

Hi,

I am having issues with developing a Win32 API-based C language GUI
application for Windows 2000/XP to test a custom PCI device/WDM device
driver I developed for Windows 2000/XP.
For this GUI application, I am using Visual C++ 2005 Express Edition +
Windows 2003 SP1 SDK, therefore, I am not using MFC.
The custom PCI device here is an FPGA-based bus master capable 32-bit
PCI device.
The WDM device driver I wrote can perform a bus master transfer using
a separate worker thread with IRP queuing and cancellation support.
The Win32 API-based C language GUI application is meant to test the
WDM device driver and the custom PCI device.
I finally finished writing the WDM device driver, but because I don't
have the GUI application ready yet, I am not able to test the WDM
device driver at this point. (Especially, I need to test I/O
cancellation I implemented with my WDM device driver.)
The GUI portion of application is supposed to be fairly simple,
however, that's where I got stuck.
Although I originally started playing around with software, and I am
now a digital hardware designer (I do FPGA designs with Verilog HDL
and VHDL.), but because I wanted to demo what I have developed on a
PC, I now have the need to learn how to write a WDM device driver and
C language Windows GUI application.
This is how I want the GUI of the application to look like.

Initial Screen:

The initial screen contains several test modes that is selectable by
clicking a radio button.
I am thinking of supporting at least 3 test modes.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will be grayed out here because there is not a screen to go
back to.
"Next" will cause a transition to test mode 1, test mode 2, or test
mode 3 screen based on the current radio button setting.
"Exit" will cause the GUI application to terminate.

Test Mode 1 Screen 1:

The user will arrive in this screen from initial screen if test mode 1
was selected in the initial screen.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to the initial screen.
"Next" will be grayed out here because there is not a screen to
advance to.
"Exit" will cause the GUI application to terminate.

Test Mode 2 Screen 1:

The user will arrive in this screen from initial screen if test mode 2
was selected in the initial screen.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to the initial screen.
"Next" will cause a transition to test mode 2 screen 2.
"Exit" will cause the GUI application to terminate.

Test Mode 2 Screen 2:

The user will arrive in this screen from test mode 2 screen 1.
The user can press a button on the center of the GUI that starts a
test.
The user can press another button that stops the test.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to test mode 2 screen 1.
"Next" will be grayed out here because there is not a screen to
advance to.
"Exit" will cause the GUI application to terminate.

Test Mode 3 Screen 1:

The user will arrive in this screen from initial screen if test mode 3
was selected in the initial screen.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to the initial screen.
"Next" will cause a transition to test mode 3 screen 2.
"Exit" will cause the GUI application to terminate.

Test Mode 3 Screen 2:

The user will arrive in this screen from test mode 3 screen 1.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to test mode 3 screen 1.
"Next" will cause a transition to test mode 3 screen 3.
"Exit" will cause the GUI application to terminate.

Test Mode 3 Screen 3:

The user will arrive in this screen from test mode 3 screen 2.
The user can press a button on the center of the GUI that starts a
test.
The user can press another button that stops the test.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to test mode 3 screen 2.
"Next" will be grayed out here because there is not a screen to
advance to.
"Exit" will cause the GUI application to terminate.

        In my opinion, the way I am trying to get these screen
transitions to work is very similar to how application installation
programs like InstallSheild handle screen transitions.
In such a application installation program, there is usually an
introduction screen the user press "Next" button to advance.
In the next screen the user usually have to accept license agreement
to move to the next screen.
The user can also go back to the previous screen or exit the
application installation program.
I am sure now you got the idea what I am trying to accomplish.
The part I am really having problems right now is how I can implement
this in my software development environment.
To write a Win32 API-based C language GUI application for Windows 2000/
XP, I have purchased Charles Petzold's Programming Windows, 5th
Edition (It is a good book, but I feel like the book has to be
rewritten pretty soon because it was published almost 10 years
ago . . .), Jeffrey Richter Programming Applications for Microsoft
Windows, 4th Edition, and Jeffrey Richter and Christophe Nasarre's
Windows via C/C++. (This book is up to date, and contains information
about Windows Vista, but not too much about GUI issues.)
        This is so far how much I have written for the GUI
application.
I read through the chapters in Charles Petzold's book related to
dialog boxes and resources.
I have read through information related to dialog boxes contained in
Platform SDK.
I also relied on a Win32 programming tutorial by winprog.org.
        Initial version of the code I wrote contained a call to
RegisterWindow and CreateWindow API functions within WinMain, and
after that there is a message loop. (That's the way Charles Petzold's
book does it, and the way SDK's documentation presents the examples.)
The window procedure RegisterWindow API function registered then
handles various messages to decide what to do next.
I used DialogBox API function to move to the next screen. (i.e., Go
from initial screen to test mode 2 screen 1.)
But the problem I had with this approach was that the initial screen
was still on the screen. (I want initial screen to be completely
replaced with test mode 2 screen 1.)
        For various reasons, I didn't like this previous approach, so
I decided to look into a different way to write the GUI code.
In the code samples of Windows via C/C++, the authors of the book has
a very simple WinMain, calls a DialogBox right away within WinMain,
and WinMain does not contain a message loop. (I personally don't like
this message loop business, so I prefer this approach.)
But I still have the problem of making transition from one screen to
another screen if I used DialogBox API function because the previous
screen is still on the computer screeen.
        In both approaches, I decided not to use CreateDialog API
function because that creates a modeless dialog box which is not what
I want. (I did experiment with it, but I didn't like the results I
got.)
I guess if I were the summerize the issues I am having with, the
problem I am having is how do I transition from one dialog box to
another, and be able to go back and forth?
Going back to the application installation program example, I know
that those programs handle screen transitions without the issues I am
having with DialogBox API function, and that is what I am trying to do
with my GUI application.
I hope I described my situation with adequate details so that someone
who is much more familiar with Win32 API programming can give me clues
as to how I should proceed from here.
I decided to invest some time in writing this posting rather than
struggling to read various books because I cannot seem to find
examples related to what I am trying to do here.
Thank you very much for reading this farily long posting.

Sincerely,

Bob

This isn't really a question about the C++ language, and is highly off-
topic here. This group is more for syntax and semantics of the C++
language itself, not GUI design or Windows API. However, that said,
there are a few tools that can help you.

I *highly* recommend checking out CodeGear C++ Builder. I'm not sure
if you've ever used VisualBASIC, but you have, this is like that, but
for C++. It's pricey but there is a 15-day trial. It's worth checking
out if you need to do rapid GUI development, I use it pretty
extensively and love having an excuse to give it a plug:

http://www.codegear.com/products/cppbuilder

Another good option is VS2005 / VS2008, create a Windows Forms
application. You get the same drag+drop GUI design as C++ Builder. MFC
is a bit dated, Windows Forms is the more recent replacement. The free
VS2008 Express edition comes with full support for this. It's fairly
easy to use.

There is also wxDev-C++, a version of Dev-C++ that comes with a
wxWidgets-based GUI editor. I'd still go with VS2008 over wxDev-C++,
but if you're going for portability, that's also an option.

If you have specific Win32 API questions, direct them to the MSDN
forums or newsgroups instead, not comp.lang.c++. You probably won't
get much more advice here.

HTH,
Jason

 

[Phil]

Hi,

I am having issues with developing a Win32 API-based C language GUI
application for Windows 2000/XP to test a custom PCI device/WDM device
driver I developed for Windows 2000/XP.
For this GUI application, I am using Visual C++ 2005 Express Edition +
Windows 2003 SP1 SDK, therefore, I am not using MFC.
The custom PCI device here is an FPGA-based bus master capable 32-bit
PCI device.
The WDM device driver I wrote can perform a bus master transfer using
a separate worker thread with IRP queuing and cancellation support.
The Win32 API-based C language GUI application is meant to test the
WDM device driver and the custom PCI device.
I finally finished writing the WDM device driver, but because I don't
have the GUI application ready yet, I am not able to test the WDM
device driver at this point. (Especially, I need to test I/O
cancellation I implemented with my WDM device driver.)
The GUI portion of application is supposed to be fairly simple,
however, that's where I got stuck.
Although I originally started playing around with software, and I am
now a digital hardware designer (I do FPGA designs with Verilog HDL
and VHDL.), but because I wanted to demo what I have developed on a
PC, I now have the need to learn how to write a WDM device driver and
C language Windows GUI application.
This is how I want the GUI of the application to look like.

Initial Screen:

The initial screen contains several test modes that is selectable by
clicking a radio button.
I am thinking of supporting at least 3 test modes.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will be grayed out here because there is not a screen to go
back to.
"Next" will cause a transition to test mode 1, test mode 2, or test
mode 3 screen based on the current radio button setting.
"Exit" will cause the GUI application to terminate.

Test Mode 1 Screen 1:

The user will arrive in this screen from initial screen if test mode 1
was selected in the initial screen.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to the initial screen.
"Next" will be grayed out here because there is not a screen to
advance to.
"Exit" will cause the GUI application to terminate.

Test Mode 2 Screen 1:

The user will arrive in this screen from initial screen if test mode 2
was selected in the initial screen.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to the initial screen.
"Next" will cause a transition to test mode 2 screen 2.
"Exit" will cause the GUI application to terminate.

Test Mode 2 Screen 2:

The user will arrive in this screen from test mode 2 screen 1.
The user can press a button on the center of the GUI that starts a
test.
The user can press another button that stops the test.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to test mode 2 screen 1.
"Next" will be grayed out here because there is not a screen to
advance to.
"Exit" will cause the GUI application to terminate.

Test Mode 3 Screen 1:

The user will arrive in this screen from initial screen if test mode 3
was selected in the initial screen.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to the initial screen.
"Next" will cause a transition to test mode 3 screen 2.
"Exit" will cause the GUI application to terminate.

Test Mode 3 Screen 2:

The user will arrive in this screen from test mode 3 screen 1.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to test mode 3 screen 1.
"Next" will cause a transition to test mode 3 screen 3.
"Exit" will cause the GUI application to terminate.

Test Mode 3 Screen 3:

The user will arrive in this screen from test mode 3 screen 2.
The user can press a button on the center of the GUI that starts a
test.
The user can press another button that stops the test.
On the lower right hand side of the initial screen, the user will see
several buttons.
"Back" will cause a transition back to test mode 3 screen 2.
"Next" will be grayed out here because there is not a screen to
advance to.
"Exit" will cause the GUI application to terminate.

        In my opinion, the way I am trying to get these screen
transitions to work is very similar to how application installation
programs like InstallSheild handle screen transitions.
In such a application installation program, there is usually an
introduction screen the user press "Next" button to advance.
In the next screen the user usually have to accept license agreement
to move to the next screen.
The user can also go back to the previous screen or exit the
application installation program.
I am sure now you got the idea what I am trying to accomplish.
The part I am really having problems right now is how I can implement
this in my software development environment.
To write a Win32 API-based C language GUI application for Windows 2000/
XP, I have purchased Charles Petzold's Programming Windows, 5th
Edition (It is a good book, but I feel like the book has to be
rewritten pretty soon because it was published almost 10 years
ago . . .), Jeffrey Richter Programming Applications for Microsoft
Windows, 4th Edition, and Jeffrey Richter and Christophe Nasarre's
Windows via C/C++. (This book is up to date, and contains information
about Windows Vista, but not too much about GUI issues.)
        This is so far how much I have written for the GUI
application.
I read through the chapters in Charles Petzold's book related to
dialog boxes and resources.
I have read through information related to dialog boxes contained in
Platform SDK.
I also relied on a Win32 programming tutorial by winprog.org.
        Initial version of the code I wrote contained a call to
RegisterWindow and CreateWindow API functions within WinMain, and
after that there is a message loop. (That's the way Charles Petzold's
book does it, and the way SDK's documentation presents the examples.)
The window procedure RegisterWindow API function registered then
handles various messages to decide what to do next.
I used DialogBox API function to move to the next screen. (i.e., Go
from initial screen to test mode 2 screen 1.)
But the problem I had with this approach was that the initial screen
was still on the screen. (I want initial screen to be completely
replaced with test mode 2 screen 1.)
        For various reasons, I didn't like this previous approach, so
I decided to look into a different way to write the GUI code.
In the code samples of Windows via C/C++, the authors of the book has
a very simple WinMain, calls a DialogBox right away within WinMain,
and WinMain does not contain a message loop. (I personally don't like
this message loop business, so I prefer this approach.)
But I still have the problem of making transition from one screen to
another screen if I used DialogBox API function because the previous
screen is still on the computer screeen.
        In both approaches, I decided not to use CreateDialog API
function because that creates a modeless dialog box which is not what
I want. (I did experiment with it, but I didn't like the results I
got.)
I guess if I were the summerize the issues I am having with, the
problem I am having is how do I transition from one dialog box to
another, and be able to go back and forth?
Going back to the application installation program example, I know
that those programs handle screen transitions without the issues I am
having with DialogBox API function, and that is what I am trying to do
with my GUI application.
I hope I described my situation with adequate details so that someone
who is much more familiar with Win32 API programming can give me clues
as to how I should proceed from here.
I decided to invest some time in writing this posting rather than
struggling to read various books because I cannot seem to find
examples related to what I am trying to do here.
Thank you very much for reading this farily long posting.

Sincerely,

Bob

I use the Visual Studio 2005 Pro project wizard, so the terms below
are meaningful to that version. Hopefully, similar terms are used in
the Express edition. I think you want to stick with modeless
dialogs. With that assumption, modify your project as follows:

Set each dialog Border attribute to None and Style to Child. If you
edit the .rc file directly, set the STYLE line to,

STYLE DS_SETFONT | DS_FIXEDSYS | WS_CHILD | WS_SYSMENU

Define as global variables:

HWND g_hWnd = NULL;
HWND hWndDialog = NULL;

In the application main function, _tWinMain, change the message loop
to be:

while (GetMessage(&msg, NULL, 0, 0))
{
if (!IsWindow(hWndDialog) || !IsDialogMessage(hWndDialog, &msg))
{
if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
}

In the window class registration function, MyRegisterClass, disable
the menu (optional):

wcex.lpszMenuName = NULL;

In the window InitInstance function after the call to UpdateWindow,
add (where Dialog1 is the initial dialog):

g_hWnd = hWnd;

hWndDialog = CreateDialog(hInst, MAKEINTRESOURCE(IDD_DIALOG1), hWnd,
Dialog1);
ShowWindow(hWndDialog, SW_SHOW);

In each dialog procedure change the button message processing similar
to (e.g., OK and Cancel buttons transitions to Dialog2),

case WM_COMMAND:
if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL)
{
DestroyWindow(hWndDialog);

hWndDialog = CreateDialog(hInst, MAKEINTRESOURCE(IDD_DIALOG2),
g_hWnd, Dialog2);
ShowWindow(hWndDialog, SW_SHOW);

return TRUE;
}
break;

- Phil