You can get vim on Windows (gvim I believe).

Make sure that both your test application and the library are linking to the same C runtime (eg both debug non-multi thread etc).

(24/08/2012 08:00 PM)ZiNgA BuRgA Wrote:  You can get vim on Windows (gvim I believe).

Make sure that both your test application and the library are linking to the same C runtime (eg both debug non-multi thread etc).

I'll try again when I'm feeling better about blowing time.

Speaking of which, I got my first library up and running (with much ease after reading all that poo poo of getting opencv to work), if anyone is interested, it's the CURL library you find in a usual PHP environment. I found it particularly handy in getting data off websites so I planned on using it in the testing I'm doing now.

Also, windows GUI programs (C++ anyway, BASIC was as simple as drag'n drop) seem to be an absolute bitch to make, specially when all these constructs seem to be really old and need a lot of documentation to understand.

(This post was last modified: 26/08/2012 04:04 AM by Tetris999.)

Somewhat depends on the framework you're using.
MFC?  WinForms?  WPF?  Qt?
Or plain Win32 API?

(26/08/2012 04:43 PM)ZiNgA BuRgA Wrote:  Somewhat depends on the framework you're using.
MFC?  WinForms?  WPF?  Qt?
Or plain Win32 API?

I switched to WinForms from Win32 API (book I was reading introduced it first and it made my head explode), the plain Win32 API is just very hard to follow wherever I go to find information on it.

I understand the construction of a window with winclassex, registering it in WinMain(), then displaying it. After that, I fall flat, as I don't understand the whole "messaging" system that they have in place.

Well I feel like I got it conceptually at least, messages are queued when things happen (the window gets dragged, keyboard gets keys clicked, etc.) and you call WindowProc to handle them. It's just that putting this all into code is extremely confusing, I think I need to find some simple examples to get the grasp of it.

Not to mention I have NO IDEA what many of the types and functions are, the biggest thing bugging me right now are things like LRESULT CALLBACK WindowProc(...)

Specially that middle word, what is that even referring to? Usually in C++ I see function declarations like RETURN-TYPE FUNCTION-NAME(PARAMETERS), but that middle term is throwing me off. I've read around that it specifies some specific return type relating to windows, but I can't make heads or tails if I'd see this normally in C++; I still don't understand what it means really.

Yeah, as you can see the win32 API is crazy, as you have to handle a lot more things than just whatever feature you want your program to perform (like redrawing the window when you move it) so I went full up nooby and used forms.

So far so good, seems really simple, the form is itself a class with a bunch of members being buttons and labels and what not, not too hard to deal with this.

As far as I know, MFC is basically the object oriented approach (and learning curve dampening) way of writing windows forms? I'll look into it when Winforms can't cut the cake for me. I also don't know what WPF and Qt are @_@.

So many things that I don't know...yawn, as for actually learning this stuff, I guess I have to keep reading.

(This post was last modified: 26/08/2012 07:52 PM by Tetris999.)

(26/08/2012 07:45 PM)Tetris999 Wrote:  After that, I fall flat, as I don't understand the whole "messaging" system that they have in place.

If you've ever done event driven programming, that's essentially what it is.
Perhaps what you're using is too low level - maybe try something which encapsulates this messaging in events instead.

(26/08/2012 07:45 PM)Tetris999 Wrote:  Not to mention I have NO IDEA what many of the types and functions are, the biggest thing bugging me right now are things like LRESULT CALLBACK WindowProc(...)

Specially that middle word, what is that even referring to? Usually in C++ I see function declarations like RETURN-TYPE FUNCTION-NAME(PARAMETERS), but that middle term is throwing me off. I've read around that it specifies some specific return type relating to windows, but I can't make heads or tails if I'd see this normally in C++; I still don't understand what it means really.

They're just aliases.  You'll probably see a lot of them when using libraries.
They may not be explained fully in a textbook, but really the idea is so that you don't really need to know what they are.
The aim of this abstraction is probably to increase portability (and readability maybe, function pointers can look ugly).  For example, LRESULT CALLBACK probably just resolves to a 32-bit function pointer.  But if you were to compile it as 64-bit, this would obviously need to be a different type.  To save you the hassle, using the predefined types will automatically set the right thing for you.

(26/08/2012 07:45 PM)Tetris999 Wrote:  Yeah, as you can see the win32 API is crazy, as you have to handle a lot more things than just whatever feature you want your program to perform (like redrawing the window when you move it) so I went full up nooby and used forms.

Not nooby, but sane.  No-one really wants to handle all this nonsense - it's really unnecessary.

Lol noone uses Windows API (for drawing a GUI) directly.  Unless you're working for a big company that produces software which sell on supermarket shelves for $100, then you use the windows API.

Go use Qt or wxWidgets or whatever.

(This post was last modified: 27/08/2012 01:32 AM by Assassinator.)

(27/08/2012 02:18 AM)hibbyware Wrote:  What type of controls are you looking to use in your GUI?

Simple buttons and whatever, not anything like rendering an opengl window of the sorts.

(27/08/2012 02:18 AM)hibbyware Wrote:  I've not messed with any for about 20 months since I made a map editor for my 3D world.

The world itself is done using opengl but I overlay a few controls for editing the map.

I remember treeview was a bitch to get my head around at the time but I managed to pull it off.

Screenshot with a few controls - http://www.mediafire.com/view/?tn26g3ftq...195wjl7zyl

You have to think of every control like a window which has it's own handle (HWND).
When the control is created you also state which handle is the control's parent window.
You use SendMessage to pass info between them,

That's pretty cool!

Also, yeah, I could wrap my head around the whole hwnd handler it's just the message loop that throws me off. It just kinda makes you wonder why you need to have a message loop in the first place, probably some higher level design that I probably don't understand yet.

Anyway, I'm going forms right now, this is a bit too much to understand atm when there are other fun stuff to be looking through ;).

Thanks for all the comments guys, I appreciate it.

(This post was last modified: 27/08/2012 09:31 AM by hibbyware.)