Page 2 of 2 First 12
  • Jump to page:
    #16
  1. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    Representin' Quebec
    Posts
    106
    Rep Power
    12
    Thanks for the link and all but that's not really what I meant... I meant: "How do I write a program that 'looks' like it?" With the not-the-usual-grey-stuff as the background?
  2. #17
  3. Cast down
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    Sweden
    Posts
    321
    Rep Power
    12
    That's a whole different story, you'd want to read up on GDI (if your serious about this, you will become really good friends with BitBlt()), and subclassing.
  4. #18
  5. Rut row Raggy!
    Devshed Novice (500 - 999 posts)

    Join Date
    Jul 2001
    Location
    Tornado Alley
    Posts
    560
    Rep Power
    31
    Originally posted by movEAX_444
    That's a whole different story, you'd want to read up on GDI (if your serious about this, you will become really good friends with BitBlt()), and subclassing.
    What about making the graphics and layout yourself w/one of the Adobe programs?
    Matt
  6. #19
  7. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Location
    Bulgaria
    Posts
    22
    Rep Power
    0
    I would like to tell you something more. If you learn the API don't expect it to be an ideal API. There is so much in it that you must spend half (not ot say all) of your life learning it. And because it is evolving over time (since year 1985) there are many things that are confusing. That' a all about BACKWARD COMPATIBILITY. Some people are very annoyed of it because they think that Microsoft can repair all the errors, they've done in the API in the past years and that backward compatibility is not so important. They are far from the truth. Of course Microsoft can develop a completely new API, that is much more logic and easy to use, but that would mean they loose all their clients, because of tons of code already written and working in the companies all over the world. These companies wouldn't rewrite completely their software, but stick with the current operating system and not buy the new. That would be a CRASH for Microsoft. Of course Microsoft can maintain two different API's in one operating system, one for current writing and another for maintain legacy code, but that would be too much and confusing. (See MacOSX for example)
    Some parts of the WinAPI are well written and easy to use, other are very hard and inconsistent. This is because of the time of writing, different teams working on different parts of the API, etc.
    I show you an example - SetFocus(hwnd) API function. What is that? Why not wndSetFocus(hwnd) ? And all the functions about windows starting with the prefix 'wnd'? That's because this function is created back in the 'dark' ages of Windows 1.0 and then there were about hundred functions in Windows and there was no need to prefix them. Who could imagine that 15 years later the API will consist of about: 4000 functions 30000 constant definitions, 900 messages, 1100 structures, 1200 error codes, etc.
    There are more inconsistancies: AVIFileOpen, mciSendString, ReadFile, BackupRead. You see: inconsistent prefixies, inconsistent naming conventions... That is one of the reasons the API is hard to learn. Microsoft try to correct this with the COM. That said that they will ship every new API in the COM format and they' ve done it for some time, but in year 2003 they still ship flat C API's and i think that's good beacause it is simple. C is a very powerfull and elegant language, but it requires some discipline of writing.
    Another reason the Windows API is hard is that it is one of the lowest level API's across operating systems today (See: Macintosh, Next, BeOS) but very powerfull and versatile.
    There are many good thinks about the Windows API (as many as the bad thinks). I admire the writers of the USER subsystem for example : all elements you work with are windows: windows themselves, controls: buttons, menus, toolbars, etc are the same windows structures, the all have the window procedure, respond to the same messages, they all work exactly the same. Not so in Macintosh. The 3 base subsystems - KERNEL, USER and GDI are implemented in a very elegant ways.
    I think the object oriented frameworks are good, but some times they become just too bloated, consider this (that is an abstract example, just to feel waht i'm talking about):

    NORMAL (procedural)

    print(a + b)

    BLOATED (fully object oriented)

    am = new math.ArithmeticManager()
    opA = new math.Operand((float) a)
    opB = new math.Operand((float) b)
    am.addOperand(opA)
    am.addOperand(opB)
    am.operator = new math.operators.Addition()
    am.executeMathOperation()
    system.io.output.print(am.mathOperationResult())

    I wouldn't like such an API, but Microsoft is shipping .NET and it si very close to that model. To me is hard to write such a code despite some people say it would make programming Windows easier. MFC is a better solution, it is a very thin layer over the API.
  8. #20
  9. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Location
    Bulgaria
    Posts
    22
    Rep Power
    0
    About the speed. Of course applications written purely in API are faster than their counterparts in MFC. C++ itself has some intrinsic features that slow it (copy constuctors, etc). Sometimes the MFC library calls code that is unnecesary to your application. There are about 100000 lines of code in MFC. If you link it dynamically there will be some delay when starting the executable because the Windows Loader must map to memory all the standard .dll's + the MFC dll which is about a 1 MB. If you link it statically your .exe ends up with about 6000 functions more written in it. It's like your app contains all the OS.
    For slowest results in app written entirely using MFC see CorelDraw ver. 8 up. If your processor is about 2GHz and you have 512 DDR RAM it's not that frustrating, but if it is 200MHz and 64 SDRAM you are about to give up working with computers anymore.
    Of course, every bad program can be slow.
  10. #21
  11. Cast down
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    Sweden
    Posts
    321
    Rep Power
    12
    Code:
    What about making the graphics and layout yourself w/one of the Adobe programs?
    yes, you make the graphics in paint, photoshop, whatever you want, but then to get them to display on top of your form.. that's the harder part :)
  12. #22
  13. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    Representin' Quebec
    Posts
    106
    Rep Power
    12
    Thanks! GDI... exactly man. Is it a bit like DirectDraw in the way it works (how about SDL?) And, about putting the layout from photoshop thing how hard is it?
  14. #23
  15. Cast down
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2003
    Location
    Sweden
    Posts
    321
    Rep Power
    12
    I really can't tell you, I actually don't use gdi32.
  16. #24
  17. No Profile Picture
    Offensive Member
    Devshed Novice (500 - 999 posts)

    Join Date
    Oct 2002
    Location
    in the perfect world
    Posts
    622
    Rep Power
    27
    >>Is it a bit like DirectDraw in the way it works (how about SDL?)

    Yes. It requires more setting up than DirectDraw or OpenGL (to avoid loosing GDI memory). Once you get the set up right there is less to do in the actual drawing than in DX or OpenGL .

    >>And, about putting the layout from photoshop thing how hard is it?

    Not too hard to do but requires skill/practice to do well.
    I presume you are talking about, window skinning to get irregular shape windows, Alpha blending for transparency or hit-testing on images.

    If you can work out ways to bebug. ie I test my double buffering by colouring the three DC's different colours and seeing which colour is displayed.

    The most common error is not realizing that most GDI calls create resources. Some of these resources can only be freed after being released from the DC.

    So it is very important to write functions where the DC is returned to its original condition and any GDI objects freed before the function ends.

    The second error is thinking that th drawing should be done in the WM_PAINT (OnPaint() ) handler.

    No game would wait until the screen needs a new frame before drawing the new frame. The game would draw the frame then call for a paint.
    The essence of Christianity is told us in the Garden of Eden history. The fruit that was forbidden was on the Tree of Knowledge. The subtext is, All the suffering you have is because you wanted to find out what was going on. You could be in the Garden of Eden if you had just kept your f***ing mouth shut and hadn't asked any questions.

    Frank Zappa
  18. #25
  19. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Location
    Bulgaria
    Posts
    22
    Rep Power
    0
    I think MFC is a very good wraper over the Windows API (personnaly i don't like 'wrappers'). Some people say it is not, but show me a better one. Once again some people (unfortunately most people i've seen) will say : '.NET is the best one, it is fully object oriented (what a cliche!!!), it is modern (what a cliche!!!) and not arcane like the API (i just don't understand what is so arcane in the API, or this is just another cliche ?!), it is the future of Windows (how many 'futures' we've seen shipping from Microsoft the last 15 years and every one is the last one ?!)'. Here is my incomplete list of popular cliches in computer programming i just hate:

    - fully object-oriented (i am just not an object!),
    - reusable (what is so reusable in CMyApp or CMyDialog),
    - scalable,
    - easy to use (there are no easy things),
    - modern (language) (what?!),
    - the next revolution (can you tell me where is the revolution in the transition from DOS to Windows 1.0 ?)
    - .NET is cool (ie. Java is cool, back in 1996)
    - componentisize all (how many COM+ applications are present in your Windows MM console control panel applet ?)
    - etc (there are tons)

    Back to your question about MFC. Yes, i think MFC is the best choice for writing commercial applications, it is a standart in many companies. A few companies write software using only the WinAPI. But MFC it is not the best choice for learning an OS. If you spend more time learning the API, MFC will be easy to you (as any other framework)
Page 2 of 2 First 12
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo