Please, does anybody have code to share that without the use of any resource displays a simple dialog box which simply says "what's your name?" and expects the user to input a ASCII string, and the returns it to the caller?
Posted on 2003-03-30 16:49:44 by Maverick
I know you can create a window and controls with CreateWindowEx right? Well, just create a window with an edit control and maybe 2 buttons (ok and cancel). If the user presses cancel, just destroy the window. If the user presses ok, make sure there is text in the edit control and do what you want with it... Very simple!
Posted on 2003-03-30 18:56:38 by Gunner
when retrieving text - just send a WM_GETTEXTLENGTH message on the edit control, allocate memory, retrieve the text into the allocated memory and return the pointer to the allocated memory.

Don't forget to free the memory when no longer in use.
Posted on 2003-03-31 03:27:19 by arkane
Don't have code to share (never bothered using dialogs) but here's a suggestion. Go for DialogBoxIndirect instead: you don't need resources, since you compile the dialog structure in memory and then pass it. Thus you avoid both registerclassing and resources.

Fake
Posted on 2003-03-31 03:27:50 by Fake51
DialogBoxIndirectParam example (unfinished, partial but it's working) :tongue:

can't paste the whole source, it's a part of my unfinished program. Dialog Template is kinda confusing... I've never seen anyone have a complete working structure... I know the structure looks like -> DLGTEMPLATE+other stuff+DLGITEMTEMPLATE+otherstuff...
[size=9]DialogMemProc PROC hWndDlg:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD


mov eax, uMsg

cmp eax, WM_INITDIALOG
je __diag_init
cmp eax, WM_CLOSE
je __diag_close
xor eax, eax
ret

cStatic DB "static", 0
fFontName DB "MS Sans Serif", 0
g_lpszName DB "Name:", 0

__diag_init:

push esi
push edi

invoke CreateFont, -1, 0, 0, 0, FW_DONTCARE, FALSE, FALSE, FALSE, ANSI_CHARSET, \
OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, \
FF_DONTCARE, OFFSET fFontName
mov esi, eax

invoke CreateWindowEx, NULL, OFFSET cStatic, OFFSET g_lpszName, WS_CHILD + WS_VISIBLE, \
10, 10, 40, 15, hWndDlg, 1900, g_hInst, NULL
invoke SendMessage, eax, WM_SETFONT, esi, TRUE

pop edi
pop esi

jmp __diag_exit

__diag_close:

invoke EndDialog, hWndDlg, 0

__diag_exit:

xor eax, eax
inc eax
ret

DialogMemProc ENDP

[color=blue]ALIGN 4
lpDlgTemplate DLGTEMPLATE<WS_VISIBLE + WS_SYSMENU, WS_EX_TOOLWINDOW, 0, 0, 0, 100, 100>
DW 0 ;??? Menu ???
DW "Q", "u", "e", "s", "t", "i", "o", "n", 0 ;Title - UNICODE
DW 8 ;Font Size
DW "M", "S", " ", "S", "a", "n", "s", " ", "S", "e", "r", "i", "f", 0 ;Font Name - UNICODE[/color]

CreateDialogMem PROC hWnd:DWORD

push 0
push OFFSET DialogMemProc
push hWnd
push OFFSET lpDlgTemplate
invoke GetModuleHandle, NULL
push eax
call DialogBoxIndirectParam

ret

CreateDialogMem ENDP[/size]
you can make and to be 0. Don't remove Align 4 it's needed over that structure.

tested on 2k only.
Posted on 2003-03-31 03:41:08 by arkane

For me resources are an unknown beast.. never wanted to use them, so I never bothered to learn them (besides to give an icon to my EXE, only that).

I'm allergical to message loops as well.. I managed to get all my DirectX code work well without them.
In all other OS's I coded for and enjoyed, there was nothing like the Win32 model. I think it's alien, awkward and wrong, and really like to avoid it.. also because I have portability in mind, and I don't want to write any code that is host-dependent (besides wrappers and drivers, of course).

I don't know why Microsoft didn't provide something as simple as a call to MessageBoxA, but that lets the user input a string. It's incredible how complex (for me) has to be such a silly thing. I probably will do it quicker by simply making my own GUI system poking the pixels directly on screen via a nice DirectDraw Lock() on the primary buffer.

What I'd need, if it's possible, is just some line of code (asm but it's perfectly ok also C or C++) that pops up a (modal, blocking) window similar to a simple message box, with a text like e.g. "What's your name?", but then (unlike a MessageBox) lets the user input an ASCII string. When the user presses the Return key or an OK button, the function returns the inputted string to the caller. The dialog box must be independent, i.e. do not need any HWND (I'll pass it the Desktop one, if I must) nor EXE resource sections, nor MASM specific macros or stuff.
Incredibly simple stuff.. theoretically, that is. Ideally one API call should have sufficed for that.
Posted on 2003-03-31 04:02:44 by Maverick
Hi arkane,
thanks a lot for your help.. but it seems to me that that UNICODE string means no Win9x compatibility (I may be wrong of course).
Anyway, donkey has kindly offered his help too, maybe he will manage to extend Win32 with a very useful new API call and solve my problem (before I code the GUI by myself via DirectDraw - and I don't mean it as a joke, at all*). ;)

*the thing that bothers me most about this solution is that it wouldn't retain the original host OS's look, something undesiderable for many users.
Posted on 2003-03-31 04:18:15 by Maverick
well maverick, sometimes to accomplish things in life is to do it the hard way. I know it's a hassle. ;)

DialogBoxIndirectParam requires the strings to be in Unicode - the API function is supported by win95++

just add a code to create an edit box(instead of static above), subclass it, trap WM_KEYUP, trap VK_ENTER, do the retrieval and return the pointer to the allocated memory at EndDialog (instead of 0)... your done!

DialogBoxIndirectParam's return value depends on the return value of EndDialog so pass the pointer at the last parameter.

Anyway, maybe I'll post a working independent function later(no parameter passing)... gotta catch some zzz's :grin:

I'll test it on win98 later too..
Posted on 2003-03-31 04:19:06 by arkane

just add a code to create an edit box(instead of static above), subclass it, trap WM_KEYUP, trap VK_ENTER, do the retrieval and return the pointer to the allocated memory at EndDialog (instead of 0)... your done!
You make things simple. :grin:
It would be easier for me to design the next generation of x86's CPU than to understand what you've typed above. ;)

I always tend to go as much low-level as possible. For example, never used any VK_xxx ... I just use DirectInput (simply because I didn't yet find the way to talk to the keyboard driver directly*).

*and it would indeed give advantages.. for example, some keys of my multimedia keyboard aren't detected by DInput and, even worse, I get simulated keys when I press the 4th and 5th mouse buttons (the lateral ones present in some modern mice).. something I really do not want to happen. When I read the keyboard I wanna read the keyboard, not the mouse.. expecially when I do it through something that dares to call itself "DirectX". Even more, I have my Explorer set up as pressing F9 opens C:\, pressing F10 opens D:\ etc.. Well, I can't grab the keyboard all for myself.. it's annoying to see an Explorer window on top of my app when F9 is pressed and it wasn't mean to be a request for Explorer. BTW: does anybody know of any lower level way to access the keyboard than DInput, and/or how to filter the keyboard so that no app other than mine get any messages from it, when I decide to grab this device?
Posted on 2003-03-31 04:32:38 by Maverick
Oh!!! So you want a DInput-like example. You didn't say so ;) :grin: I don't have one :tongue:

*maybe I'll cook up something l8r*

try GLUT (keyboard functions) for the mean time - it's "portable". Never tried it though.

IIRC DInput is the lowest you can get - granting that your app will work on all dx-installed platforms(windows :grin: ).

try a global hook on f9 and similar keys, maybe that will help.
Posted on 2003-03-31 04:37:17 by arkane
Maverick,

The in memory template system is already up and going in the current version of MASM32. The main fun is the alignment for the data which is critical but you are welcome to translate them to any other language you like and the system does work well. It uses ANSI strings for text storage and converts them on the fly to UNICODE which all 32 bit versions of windows use with dialog boxes.

I did it as a set of macros that just plug together so it should not be a big deal to port them to another assembler or perhaps C if you wanted to.

All of the macros are in the INCLUDE directory in a file DIALOGS.INC and there is a help file to show how they are put together.

Regards,

hutch@movsd.com
Posted on 2003-03-31 04:47:02 by hutch--

Hi arkane, you wrote:
Oh!!! So you want a DInput-like example.
A DInput like example? ;) Rather the opposite. I've no problems with DInput knowledge, I have problems with the GDI instead.

try a global hook on f9 and similar keys, maybe that will help.
Thx.. I'll try to dig on this issue following that direction. Although a nice direct access to the keyboard driver would be great (I'm already doing this for sound).



Hi hutch, you wrote:
The in memory template system is already up and going in the current version of MASM32. The main fun is the alignment for the data which is critical but you are welcome to translate them to any other language you like and the system does work well. It uses ANSI strings for text storage and converts them on the fly to UNICODE which all 32 bit versions of windows use with dialog boxes.

I did it as a set of macros that just plug together so it should not be a big deal to port them to another assembler or perhaps C if you wanted to.

All of the macros are in the INCLUDE directory in a file DIALOGS.INC and there is a help file to show how they are put together.
Thanks.. but what for you may seem quick and straightforward for me is a walk in the desert. I think it's absurd to go through all of this hassle for something that is only slightly more than a simple MessageBoxA call. :P
When a coder (me in this case) feels it's easier to code his own GUI than to use an already existing GUI, there must be something wrong in the latter, at least from the point of view of "hardware banging" style coders like me, that when they want a "A" on screen they're tempted to shoot the pixels directly on screen.

Anyway.. I hope donkey will manage to help me.. otherwise I'll do the GUI drawing myself via a DirectDraw Lock() on the primary surface.
Posted on 2003-03-31 05:37:22 by Maverick

Thank You to all those that helped, but after some studying of the GDI API I decided it is way more complex than it had to be, so I'm simply making my own GUI via DirectDraw, on top of a simple GDI window.

This gives me some advantages:

1) Total, low-level control.
2) Per pixel variable transparency, alpha-masked shadow and other special effects on all versions of the Win32 OS's.
3) Non-standard GUI look.

But also some disadvantages:

1) To work always well, my window must be the topmost.
2) Non-standard GUI look.

For the rest, it supports Drag N'Drop files and Clipboard like all the other windows.

I attach an early screenshot, feel free to criticize it. :)
Posted on 2003-04-03 14:50:12 by Maverick
Crazy bastard.
Posted on 2003-04-03 18:52:04 by comrade


I attach an early screenshot, feel free to criticize it. :)



Reminds me on some ugly KDE themes ;)

Wonder why you still use Windows when you hate the GUI. Use Linux or get a Mac ;)

And for the easy "whats your name?" Dialog:



name$ = Input$("Whats your Name?")


Interprets fine in VB :grin:
Posted on 2003-04-04 00:56:04 by bazik
Maverick,

I think it looks great.

Regards,

hutch@movsd.com
Posted on 2003-04-04 02:01:35 by hutch--
looks sorta cute, maverick. I prefer standard windows look for standard things, though. And I think you're mad for doing this with DirectX :)
Posted on 2003-04-04 02:04:57 by f0dder

bazik: as if I had a choice!
You know, when you want to make a living out of it, it's not that you can dismiss an OS just because it sucks :grin: when it's used by most++ people out there. You've simply to support it, but trying to dig into itself as little as possible (use wrappers, etc..).
You mentioned VB.. argh.. now I need to go back in the bathroom and clean my ears. :mad:

;)



hutch: thanks :) I'll have to improve it though.



f0dder: thanks :) Yup, I always prefer the way "I did it myself".. so if I could bypass DirectX, and there was a sensible gain from it (it doesn't have to be specifically performance), I'd definitely go for it.



comrade: thanks :grin:
Posted on 2003-04-04 02:10:15 by Maverick


You mentioned VB.. argh.. now I need to go back in the bathroom and clean my ears. :mad:


:grin:

When you release your OS, and it takes more than one line of code to create a dialog asking the user for his name, I will remind you on this thread here ;)
Posted on 2003-04-04 02:54:43 by bazik