Index
> Windows > Windows vs dialogues? |
| Author |
|
|
revolution 28 Mar 2021, 18:13
I doubt there is any significant difference between them.
The only change is in how the internal flags are set for the controlling objects. After that Windows just renders them for you. |
|||
28 Mar 2021, 18:13 |
|
|
Overclick 28 Mar 2021, 19:38
Best choice is to begin by Dialogues.
1) Easy to create Window-form at any resource redactor with many kind of items (buttons etc) 2) No need to worry about msg-loop. 3) Almost the same to Window even if you want to render some items individually. 4) Windows have more freedom but not many people actually need that. Freedom adds more routine to do. |
|||
|
28 Mar 2021, 19:38 |
|
|
DimonSoft 29 Mar 2021, 18:36
In fact, dialogs are good until one tries to do complex UI. The problem is that control sizes are given in dialog units when one builds a dialog template but then, when you handle dialog resize and stuff you have to call SetWindowPos/MoveWindow which take pixels. Conversion is not quite straightforward (calculations are relative to dialog font size, AFAIR), add the complexity of supporting High-DPI and other brand new features. Not to mention that dialog procedures are like window procedures but with additional complications. What one really gains is being able to just invoke IsDialogMessage and get keyboard navigation work. Now ask yourself which properties of the solutions are pros and which are cons for your project.
|
|||
|
29 Mar 2021, 18:36 |
|
|
Overclick 29 Mar 2021, 19:08
Example of moving multiwindowed Dialogues:
Sticked child Code: devices_dragwindow: invoke ReleaseCapture invoke SendMessage,[hWnd],WM_SYSCOMMAND,61458,0 mov rax,1 ret devices_wmmove: invoke GetWindowRect,[hWndMain],_rect mov r11d,[_rect.bottom] sub r11d,[_rect.top] invoke GetWindowRect,[hWnd],_rect sub [_rect.top],r11d invoke SetWindowPos,[hWndMain],0,[_rect.left],[_rect.top],\ 0,0,SWP_NOSIZE+SWP_NOZORDER xor rax,rax ret Main Dialogue Code: dragwindow: invoke ReleaseCapture invoke SendMessage,[hWnd],WM_SYSCOMMAND,61458,0 mov rax,1 ret wmmove: cmp [status_DlgChild],0 je @F invoke GetWindowRect,[hWnd],_rect invoke SetWindowPos,[hWndChild],0,[_rect.left],[_rect.bottom],\ 0,0,SWP_NOSIZE+SWP_NOZORDER @@: xor rax,rax ret No problem to mapping items coordinates for resizing by same way. You do that any way. Dialogue = Window + easy start. Then you can modify it whatever you want. |
|||
|
29 Mar 2021, 19:08 |
|
|
DimonSoft 29 Mar 2021, 21:15
The point is that one has different units in the dialog template and at runtime. Plus let’s change fonts in the dialog. For projects where cons take less than one gains from pros dialogs do work well.
|
|||
|
29 Mar 2021, 21:15 |
|
|
Overclick 30 Mar 2021, 02:31
You don't need to use that template it's optional.
To change the fonts you can use 3 different techniques: 1) Stretch textures 2) Draw whatever you want 3) WM_SETFONT Example: Code: invoke CreateFont,30,0,0,0,FW_NORMAL,0,0,0,ANSI_CHARSET,\ OUT_CHARACTER_PRECIS,CLIP_DEFAULT_PRECIS,\ DEFAULT_QUALITY, DEFAULT_PITCH,'Courier new' invoke SendDlgItemMessage,[hWnd],404,WM_SETFONT,rax,TRUE |
|||
|
30 Mar 2021, 02:31 |
|
|
DimonSoft 30 Mar 2021, 07:46
Sorry, it seems you reply to somebody else.
I never complained about having to build dialog templates, they’re quite convenient as a replacement for rich Delphi-like environments. I never said one can’t change fonts: it would be stupid, everyone knows a dialog is a just a window of a system-defined class that is in cahoots with the system in certain aspects. And no, thanks, stretching textures to display text in a program with complex UI is not what I will ever consider: in 2021 we spend a lot of time to support High-DPI systems instead of letting them stretch our windows for us at compatibility layer, so stretching pre-drawn UI elements/texts ourselves is definitely a step back. And yes, what’s left is to draw everything directly, with High DPI in mind and as font-settings-agnostic as possible. Having dialog units which are “¼ of the average character width” for x coordinate and “⅛ of the average character height” for y coordinate and mapping them to pixels every now and then? No, thanks, just give me my pixels right away. We’ve fought for pixels to be nearly-square since like CGA times and today we have them. Which means we can forget restricting ourselves to x- and y-axis aligned values. Can I have a 45-degrees rotated UI element with size based on other element sizes which looks great with any font and any DPI selected, please? And I hope you don’t try to tell me I should draw everything by hand and use dialogs just to create windows. I’m OK with calling another RegisterClassEx, replacing DialogBoxParam with CreateWindowEx and controlling the message loop myself. |
|||
|
30 Mar 2021, 07:46 |
|
|
bitRAKE 30 Mar 2021, 09:38
Sadly dialogs are just a throwback to the 16bit windows days and never modernized. Many people switched to alternatives because they wanted a "system" that worked with their design. Even MS abandoned them - so few windows 10 apps use them. The WinUI 3 is the current flavor being pushed.
Wasn't there a tool that converted dialog templates to standard window functions? _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
|
30 Mar 2021, 09:38 |
|
|
Overclick 30 Mar 2021, 12:32
bitRAKE, Everything on Win 10 looks like 16bit windows ))) WinUI represents everything include it's own dialogues. Can I see some examples of WinUI on fasm somewhere?
DimonSoft, check up how Windows does stretch icons. It works both ways. You can rotate it or stretch by corners too. It's not big deal to use EnumChildWindows or something own to do routine that windows does. I'll say again Dialogue is a Window with all of that functionality. You can always get back to routine or pass it on. You can register your own class or modify exist one. Different is how you begin your project, how you declare predesigned items that is all. The rest you can add or modify by same way as Window does. |
|||
|
30 Mar 2021, 12:32 |
|
|
bitRAKE 30 Mar 2021, 12:42
Overclick wrote: Can I see some examples of WinUI on fasm somewhere? https://docs.microsoft.com/en-us/windows/apps/winui/winui3/ https://github.com/microsoft/ProjectReunion (From the roadmap, unpackaged desktop apps are planned for Q4 2021.) The browser is the UI rendering platform going forward. :/ _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
|
30 Mar 2021, 12:42 |
|
|
DimonSoft 30 Mar 2021, 15:42
Overclick wrote: DimonSoft, check up how Windows does stretch icons. It works both ways. You can rotate it or stretch by corners too. Not sure why you’re talking about this. Window icons are just small, and quite useless user-task-wise, pieces of UI. I’m more concerned about controls user interacts with having usable sizes and smooth appearance on a wide set of monitors. Quote: It's not big deal to use EnumChildWindows or something own to do routine that windows does. I'll say again Dialogue is a Window with all of that functionality. You can always get back to routine or pass it on. You can register your own class or modify exist one. Different is how you begin your project, how you declare predesigned items that is all. The rest you can add or modify by same way as Window does. Exactly. But I can spend hours trying to convince dialog class to do what I need, digging through all the compatibility stuff and the quirks of DLUs… in fact, just reimplementing most of it from scratch. Or I can just do it from scratch in the first place. It’s like a choice between buying an old building to demolish it and build a new one and buying just plain land with nothing built on it. The second way seems to be cheaper and lets avoid dealing with sewer pipes buried in the ground. Still, dialogs are a great way to go for simpler projects with relaxed requirements or for proofs-of-concept that should be written faster. |
|||
|
30 Mar 2021, 15:42 |
|
|
Overclick 30 Mar 2021, 16:46
Quote:
I see you don't know. There is few sizes and windows stretch closest one. You can load 4k textures and stretch them to smaller size. Or you can use resizing by fixed steps. Quote:
You can modify class to your own, it's very flexible. Just set the name of new class into resource editor. Ofcourse if you don't need any default items even text, textures or draw items then you don't need Dialogue at all. Quote:
That what I'm trying to say. |
|||
|
30 Mar 2021, 16:46 |
|
|
DimonSoft 30 Mar 2021, 23:08
Overclick wrote: I see you don't know. There is few sizes and windows stretch closest one. You can load 4k textures and stretch them to smaller size. Or you can use resizing by fixed steps. I do. Everyone who has ever tried to write a resource section in FASM had to dive into the details of how icons are stored as resources. But windows icons are used in very specific places with metrics almost exactly known in advance. Which really differs from complex UI. Window icons are the easiest part: one can just prepare the icon in a few sizes and it should work for most cases. Even if it looks bad, it doesn’t make user experience terrible, just aesthetical attractiveness goes a bit down. Compare this to program window or certain controls inside it being extremely small at 16k monitor up to the point of their text being too small to be readable. Overclick wrote: You can modify class to your own, it's very flexible. Just set the name of new class into resource editor. Dialogs don’t work by plain magic. If it quacks like a dialog, one still has to cooperate with dialog manager. And the word “quirks” is not arbitrarily chosen: DLUs are only one of them and it once took Raymond Chen 9 blog posts to explain just a few. But we’re still waiting as he said it was enough “for now”. |
|||
|
30 Mar 2021, 23:08 |
|
|
Overclick 31 Mar 2021, 00:25
Quote: dialog manager Dialogue manager works via predesigned Window msg-loop. It can accept almost all kind of "window" commands. Othervice it have similair alternative. I tried, it's very funny. And yes, class can be modified, I did that for my own. Just show me some your examples I'll try to make them run via Dlg. Quote:
Another stupid classes and methods? Or even more -- nothing to do by assembly? Do you believe it won't be visually limited for next years? MS sticked to their Surface as privileged platform for all past years. And now they provide another "super fast" stupid tiles UI for small slowly tablets? Do someone have performance issues with old UI even aero except tablets users? I don't think so. Old-school Windows will stay popular for long... |
|||
|
31 Mar 2021, 00:25 |
|
|
DimonSoft 31 Mar 2021, 14:08
Overclick wrote:
Nobody argued that. It’s just a matter of how much one gains and how much it costs later. Overclick wrote:
Sorry, you clearly don’t know what you’re talking about. DLUs are one of the basic things one faces when they start to use dialogs. And Raymond’s blog as well as the dialog manager series are exactly about old-school Windows. Why would a guy who was responsible for old-school Windows user-mode services, including window and dialog managers, write about anything else? There was no notion of any modern Windows “technology” in any of my posts here. Just High DPI monitors but they do not replace old-school Windows programming, they just require a programmer to be aware of new hardware that gained significant market share in the period of time that has passed since CGA was a shiny brand-new catch word. |
|||
|
31 Mar 2021, 14:08 |
|
|
Overclick 31 Mar 2021, 14:12
Quote:
I just guess. I don't know him. Good if so. Thanks for hint. Seems I need to add Scale option for my exist project too |
|||
|
31 Mar 2021, 14:12 |
|
< Last Thread | Next Thread > |
Forum Rules:
|