pouët.net

looks to be more than it is huh, but thats just this topic's fault.

navis: also not everybody wants to install several megs of stuff, possibly compile the shit (wxWidgets), use some meta-compiler (qt) and shit just to have some simple windows...

I know :/

but it still looks very very ugly...

jar_: That's why I kinda like ATL/WTL. WTL is not very big, and it wraps this stuff up quite neatly already. No point in reinventing the wheel, aye? :)

What's wrong with using Win32 for simply opening a window for a demo/intro?! I agree that when it comes to MDI and so on, it becomes ugly quickly and that WTL or Qt are much better, but come on, for simple stuff...

On the other hand, compare the time it takes to "install several megs of stuff" to the time it takes to figure out why your windows are repainting on top of one another. In the case of Qt, the only thing the user will have to install is a DLL alongside the executable (if you're not statically linking which I think is an option too), and the framework itself is just really, really good. The only real downside is that if you want to do closed-source projects you need a commercial licence.

rare: But if you're doing window classes isn't that a clear indication that you're not doing "simple stuff"?

Yeah, probably ;)
Dunno what rydi's doing though...

what im doing? im thinking of smokin some cigarettes right now and hopefully ill get cancer by the time i get fifty. i dont know what to say except for that im not just using this for just opening a simple window for a demo, its much more than that. im trying to learn the fucking win32 api -shit without using libraries like jar_ said.

Navis: what looks ugly? Your ass looks ugly!

I'm with your side man... I'm with your side :)

now what the hell does that mean.

i havent taken a closer look at the win wrapper class (and for a demoengine i wouldnt even bother putting trivial shit like a window init / management in its own wrapper class -- just to be clear) but it isnt that vile.

placing a few sdl calls or whatever is fine too but likewise code will have to live somewhere anyway :)

if you need a message loop + window for a demo, just copy it from the dx9 tutorial example. that's just a few pages of code you never need to understand.

getting mouse, keyboard, 3d and 2d all working at once, like for a mixed 2d/3d tool, is a little bit more work, and i'm not sure you can do that with off-the-shelf-open-source-libs, if you want DirectX (which i prefer over OpenGL).

and yes, you can write a windows app that does something meaningful in just a few hundred kilobytes. and it is really cool to see it load in well under 16.67 milliseconds, everything slower is not acceptable beyond 2.4GHz cpu clock speed. that's why i think you should not always use all the libs ever written.

im not sure if the tool im working on is going to be big or not, what i know though is that its going to be some windows(child i think) and dialogs for other stuff. problem is what to put where. i wonder, chaos, you've made a tool for farbrausch right? what is best to do for Managers like texture, scene, etc.. put those all in windows or dialogs? i mean by using dialogs you can make all the buttons, editboxes, checkboxes etc in a resource editor, but with a window you can't? anyway its no problem to write a own tool for that or just punch in the numbers by hand. I wanna know more about what MDI can do and if it is relevant for a demotool.. I could make everything dialogbased but i dont want to if it totally fucks up the design.

Sounds to me like you're overthinking it, Rudi. Perhaps you should try to make something simple, and extend that later instead?

what i do i would not recommend other people to do. i wrote my own gui toolkit, and it's really cool. actually, i wrote a whole new toolkit for every werkkzeug... spend more time with that than coding demos. it can be fun.

i just open a window, intercept key & mouse, and do all the drawing with FillRect, ExtTextOutW, BitBlt, StretchBlt & LineTo. popups, buttons, all hand made. i have 15 years of experience in gui toolkit design and make the most of it, just don't think it is simple to build a workable gui out of simple things without some effort.

MDI seems somewhat superfluous to me, personally. With a properly defined window class, like you seem to have already (or like you'd get with one of the many available ready-made frameworks ;) ), you can spawn as many windows as you want anyway with zero effort, and they can still be tied to a main application window, but without having to be trapped in a box (which is really only annoying at the end of the day) and needing special attention because they're MDI children.

rydi. Probably speaking for all people in this thread: Do yourself a favour and chose a proper framework if you want to save yourself a lot of work.
I would never ever again code something with Win32 except small intro/demo/screensaver stuff. Even for small tools <insertframeworkhere> saves you lots of work and lets you concentrate on the core functionality you want to achieve...
I personally like Qt, because of functionality (GUI, drawing, printing, OpenGL, XML, SQL, <nameit>) and portability (Windows/Linux/Mac).

Other than that I second chaos. ;)

But hey, go ahead. If you desperately wanna learn about the Win32-API, do it.

yep, you have three options:

1) implement your own "generic" UI toolkit. it's worth the effort but there's a freaking lot of effort involved (i.e. I second chaos)

2) use one of the existing "platform agnostic" toolkits (SDL, PTC, etc..)

3) concentrate on the very platform and "hack it" :D

(..but any combination of 1..3 may work, too...;) )

i choose 1.

http://sol.gfxile.net/imgui/index.html Could give you a new look into how gui's could be programmed for games and demos in a non-traditional way.

I also enjoy coding gui stuff my own way and been doing so for about 8 years now and then (had to do it professionally at first), but it really needs a solid design just to get you half way to your goal so design as much as you can before you start coding. Days, literally. Weeks preferably.

Think about: Event handling between your widgets and the application. If a state changes, how do the application knows? Other widgets? How du you support multiple layer of widgets and their focus? Always on top? Maximizing of components? Those are just some of the stuff I had to figure out which gave me headaches along the way :-) Perhaps I should write how I did it some time.... :-)

Btw, my gui looks like this: http://thec.org/xwork10.png or it could look like something completely dirfferent: http://thec.org/panorama37.png depending on configuration.

No, I don't claim to know everything or anything about creating guis, it is totally the wrong way to go since there are great alternatives out there (gtk, qt, fltk comes to mind). But it is a extremely funny thing to get going because of the software engineering which goes into it so just do it for fun!

And btw, implementing truetype support is _hard_. I've done it through freetype2 library once before but I'm going to go with my bitmap fonts from now on I think. Sure there are calls for it in direct x and maybe in gl too, but to make everything cross platform, and perhaps cross rendering models is just too damn boring :D

it seems that MFC is a dirty word, but i don't know why except people fearing the unknown. if you don't fight against it but work with it, it's easy really.

our demotool is written entirely using mfc. its been in rolling development for about 7 years, yet the basis is still solid. virtually all the controls are custom controls - i.e. we inherit CWnd, handle rendering in OnPaint and hit testing / interaction on OnLButtonDown etc. Rendering a control is largely achieved using CDC::DrawIcon / FillSolidRect / DrawLine / DrawText etc. Rendering text, shapes, icons and so on is dead easy, and a lot of stuff is handled by windows for you - e.g. focus, dragging/resizing windows and so on, and its very easy to piece together an app from lots of separate component windows/controls.
There's a lot of good resources to help you out there. CodeProject has useful things like CMemDC (render to an offscreen buffer - flicker free controls :) ), and dockable window libraries.
It's easy with this approach to add 3rd-party components too - e.g. i added scintilla recently and it dropped in in a couple of hours.
People often hate MFC because they fight against it - hacking around things rather than doing things the "proper" way - or they had bad experiences with common controls like the tree control or list control, which are rubbish. We have our own, it's easy to write, much easier to use and looks much nicer. Or they tried to do tricky things like dockable windows - which are difficult using native mfc, but arent really any easier in c# either. or they assumed they had to make the whole app using the dialog editor / code generator in visual studio. :)

btw - we've used qt here and i personally think it's pretty hideous - in terms of coding and the resulting applications/provided controls. but if you really have to make it work cross-platform, i guess your options are limited.

And not to forget, if you code MFC you have an easier way to move into applications programming in the professional field as well. If that's your thing.

i personally liked wx, both from c++ and python

It seems there's something I've not understood. I thought you could easily do it using the GDI function TextOut. As shown in http://www.students.meduniwien.ac.at/~n0102122/miscellaneous/justify1.zip.