Using Dynamic Dialogs

[Charles Pegge]

Many thanks, Roland,

These are very useful demos, especially for our new PowerBasic friends.

Hope you are feeling better. Extra Vit D is a Winter essential for we Northerners. The immune system does not work effectively when it is short.

[Aurel]

These are very useful demos, especially for our new PowerBasic friends.

yeah ..poor people they stucked with Dialogs... 
hmmm i remember when Eros like to..
patronize me how Powerbasic can create Window but most examples is with Dialogs.
ThinBasic is based on Dialogs too..
I dont say that Dialog type of window Form is useless but Dialog purpose is
little bit different than Window type of form ...and
today in most GUI programs , programers use Window type because is standard and
more flexibile than Dialog

[jcfuller]

Aurel,

  Show me something you can do with a window that you cannot do with a dialog.

James

[Aurel]

From cpp forum:

Dialogs are easier to create for very rudimentary apps (for example, just something that you want to do some processing at the click of a button, and nothing more), but for anything more than that, I'd avoid them like the plague. I personally don't use dialogs at all. I code everything with CreateWindowEx().

See the deal is, dialogs make use of something known as the 'Windows Dialog Engine'. There is an internal registered window class for dialogs, and it uses a modified window procedure with different messages than a standard window procdure.

The problem comes in where beginners try to get off easy and use the Windows Dialog Engine for apps that should really be RegisterClassEx() / CreateWindowEx() apps. They save a little time at first, then run into excrutiating difficulties. Seen this happen countless times.


The real Window Procedures for dialogs are inside Windows. You'll also note some of the messages are different. There is a WM_INITDIALOG message instead of a WM_CREATE message. Also, there is no registration of a window class nor a message pump. All this is within windows.

If you are content writting one window applications such as the template produced by Code::Blocks, and the structure of your window is quite simple, i.e., just push buttons or combo boxes and so forth, then it might work best for you to just use dialog boxes for a 'Main Program'. Where it seems that the problem comes in from my experience is that its so easy to produce a GUI this way, once someone does it they decide this is all there is to it and start trying to create more complex applications out of dialog boxes. In other words, they try to do fancy keyboard navigation, they want scroll bars, multiple forms, so on and so forth. That's where the trouble comes in. Truth be told, all these things can indeed be done with dialog boxes, but it soon becomes one hack after another, and it becomes more complex than just using a proper RegisterClass() /CreateWindow() setup, i.e., a standard Windows SDK style app.


I agree with this guy !

[Mike Lobanovsky]

Show me something you can do with a window that you cannot do with a dialog.

Try pressing incorrect keyboard keys in a dialog window but first be careful to lower the audio volume to avoid inadvertent contusions of innocent people dwelling in the neighboring apartments.

General frame windows would just silently ignore someone's mulling with the keyboard keys out of sheer curiosity.

Will that count? 

[jcfuller]

Mike,
  Yes
I was spoiled early on with VB and also the old Borland resource editor. As we discussed somewhere else I also used my own dialog template engine for most of the commercial work I did. I did use an sdk window as my main window in many apps but most others were dialogs. I did switch to firefly for the last couple of years of commercial work, but there were/are just too many globals for my taste. Of course I know there are limitations. One limitation I did find early on was mdi, but as far as I recollect that is politically incorrect now.

Well, with my dlg2src you can have it anyway you want it

James

[Mike Lobanovsky]

James,

In fact MDI was the first thing to come to my mind. I love it and I use it whenever I can. It is in fact a desktop within the desktop solution, gorgeous if controlled properly.

And it is also one unique Windows feature natively infeasible under other OSes. Hence its arguable "political correctness". I love to watch linuxoids fall into a stupor when they need something developed under Windows and for Windows to be ported urgently to their platform but see MDI and start scratching the backs of their heads with their faces sour at the thought how pitiful their SDIs are going to look in the end.

[Arnold]

Hi Charles,

I (hopefully) managed to add some improvements in Dialogs.inc to simplify the creation of dialogs. This would now be the way e.g. for a modal dialog:

Dialog( 0, 0, 150, 100, "Main Dialog",
             WS_OVERLAPPED or WS_SYSMENU or DS_CENTER )

DefPushButton( "Go", 1000, 30, 70, 40, 12 )
PushButton( "Close", IDCANCEL, 80, 70, 40, 12 )

CreateModalDialog( null, @MainDialogProc, 0 )

The difference is: there is no need to specify the count of the controls in Dialog(), and there is no need to allocate memory for a lpdt structure, and lpdt does not have to be specified as a parameter in Dialog() or CreateModal/ModelessDialog(). This should all be handled in Dialogs.inc. In Dialogs.inc I now included Corewin instead of Minwin, removed the namespace option and added some often used constants and added MSFTEDIT_CLASS for Richedit ver 4.1 (Msftedit.dll). I also removed WS_GROUP as a default style in the controls, this seems not to be the best way.

Attached are the modified Dialogs.inc file and the adapted WinDynDialogs examples (plus one more by MichaelW, Grouping.o2bas) which can be run in 32-bit mode and also be compiled to 64-bit exes. In my opinion the examples look much clearer now.

There are still some items which could be added to Dialogs.inc. Until now I have not found an example using creation-data, otherwise I would try to add this feature too.

Roland
 
Edit: Small typo in Listview.o2bas; line 201 should be:
             Dialog(0,0,144,77, "About Listview Sample",

[Arnold]

Compiling the examples to 64-bit exe I found problems in Toolbar.o2bas (% TTN_GETDISPINFO= -520), TabControl.o2bas (%  TCN_SELCHANGE= -551 and % TCN_SELCHANGING= -552). So in these cases I used dword instead of % which work in 32-bit and 64-bit.

RichEdit2.o2bas has a special problem in 64-bit which I probably cannot solve. In 64-bit mode pt.x and pt.y only receive the value 0, in 32-bit mode the correct coordinates are used. What could be the reason for this different behaviour? In particular I do not understand why loword(wParam), hiword(wParam) will work, but loword(lpmsgfilter.lParam),  hiword(lpmsgfilter.lParam) will fail in 64-bit mode.

 

[Charles Pegge]

Hi Roland,

Many thanks for the updates.

Re RichEdit 64bit
I found an error in windata.inc: NMHDR

this is the corrected type:

Code: [Select]

  type NMHDR
  sys     hwndFrom
  dword   idFrom 'not sys
  dword   code
  end type

But the right-click is not detected, so there's another problem somewhere.

Re: Toolbar 64bit
This works

Code: [Select]

% TTN_GETDISPINFO= dword -520  '64-bit okay


[Charles Pegge]

This works for richedit2 32bit/64bit. (after much hacking!)

MSGFILTER appears to require a packed structure, and the original NMHDR prevails, contrary to MSDN documentation.

Code: [Select]

type NMHDR
  sys    hwndFrom
  sys    idFrom
  uint   code
end type

packed type MSGFILTER 
  NMHDR nmhdr
  uint msg
  sys  wParam 
  sys  lParam
end type


[Arnold]

Thank you Charles. I did not consider "packed type" at all. But now everything works fine.

[Arnold]

Hi Charles,

I experimented a bit with negative constants in 64-bit (in 32-bit there is no problem) because I am still looking for a rule of thumb in these cases.

For constants used in notification messages your solution is the best:
% ConstName = dword -value

I also found that if I follow the MSDN defintions there is also no problem, e.g.:
DWORD GetFileAttributes(
  LPCTSTR lpFileName    // address of the name of a file or directory
);

So: % INVALID_FILE_ATTRIBUTES = dword -1 and using: "dword attrib" this will work in 32-bit and 64-bit for this example:
http://www.oxygenbasic.org/forum/index.php?topic=1544.msg18057;topicseen#msg18057

But I suspect that generally using: dword -value for negative constants would not be satisfactory neither.

Is there a difference between dword and uint?

Roland

[Charles Pegge]

Hi Roland,

It's a strange situation. If an OS call expects a 32 bit value then it should ignore the upper bits completely. Something wrong with VisualStudio ?
 
uint is the same as dword

[Arnold]

Hi Charles,

in the attachment WinDynDialogs.zip of Reply #37 there is a file Listview.o2bas with a typo in line 201:
              Dialog( 4, 0,0,144,77, "About Listview Sample",
this should be:
              Dialog( 0,0,144,77, "About Listview Sample",

Although there will be created a handle for AboutDlg, the dialog will not be shown due to the following garbage. In Dialogs.inc I apply this declaration:

sub Dialog( short x,y,cx,cy, string title, dword style,
           optional short pointSize=0, string typeFace="", dword extStyle=0)

Is there a way to check if the fifth parameter is really a string, starting with " or ` ? I do not know how this is achieved in other languages.

Roland