i got the source code for my problem

as you may know, a little while ago i posted a windows programming problem and the problem was: when you click "new", it pops up an error saying something bad. and wont create the window. mdi_unit.c is included here. in the next post, mdi_unit.h

mdi_unit.h

it doesn't even compile for me...

you need to have your compiler option set to win32API or win32GUI and not win32console. other than that, you need both files in the same project and stuff.

if it still doesn;t compile. i dont know, cuz frig...it still compiles for me!

>>> it still compiles for me!

Just because somethiong compiles for you, does not mean it will necessarily compile for someone else. It did not compile for me either, and quite rightly so, it would seem your compiler/environment allows you to use a construct which is non standard. You should learn to use standards, if not, one day you will use some construct you have alwaysgot away with and it will fail. In this case, you need to review how to cast a value, in this case, the return value from GlobalAlloc().

Next, you need to decide whether you are working with Win32 or old stuff. GlobalAlloc() is a "for compatibility" inclusion in Win32, it's use is deprecated.

So looking through your code, we call your LoadFile() function. The return value, (bSuccess), is set to FALSE upon entry, it is never set to anything else, so regardless of waht happens, you return FALSE.........

my compiler is updated constantly. so im working with the new stuff (at least i think so anyways).

but lets see, is it false or is it true. ill take a look. thanx.

First off, you should probably tell people they need to link the comctl32.lib when compiling the program.

Your problem is located in WndProc, you'll want to find:

Code:

---

              mcs.szTitle = "DarkType Unsaved Document";

---

and change it to:

Code:

---

              mcs.szTitle = "[DarkType Unsaved Document]";

---

Since in your MDI child create message handler tries to load a file if the child window's title doesn't start with "[".

See:

Code:

---

        if(*szFileName != '[')
        {
            if(!LoadFile(hEdit, szFileName))
            {
              MessageBox(hwnd, "I Couldn't Load File.", "WHOA THERE!!! SETTLE DOWN!!!!",
                  MB_OK | MB_ICONEXCLAMATION);
              return -1; //cancel window creation
            }
        }

---

I tried the fix, and it sees to work now for me, so hope that helped.

actually all i needed to change was bSuccess = FALSE to bSuccess = TRUE and it worked fine.


i use DEV and it just works for me. im new at compiling and i have no idea what that dll file does or what its there for.


actually, i would like to know what dll files actually do. Dynamic Link Libraries, that tells be that it can be changed at any time and its full or directional links or something...

how close am i? :p

anyways ill put square brackets around DarkType Unsaved Document. thanx :D

sorry, i wuld have just edited my previous post. but for some reason it wont alloow me too.


anyways. sorry, i thought it was a dll, not a .lib. hehehe, my bad!

comctl32.lib is the library that contains the common controls. If you use common controls in your program, you must link with that library. If you are not specifically doing so, your IDE must be doing it for you. Not all will, Visual C++ for example, does not.

When you write code that is going to be used be several programs, creating a library is a common solution. When you link to a library at compile time, that is called static linking, and the executables from the library are included in your module.

A .dll is a different type of library. It's executables are not added to your module. When you access a .dll, it is at run time, and the executable is mapped into your processes address space so you can use it.

Using a .dll makes your modules smaller, but means you have to ship the .dll with your program.

so thats the disadvantage eh? hehehe. dll's i find everywhere. what do you think are better? libs or dlls?

>>> what do you think are better? libs or dlls?

No correct answer to that. Sometimes one, othe times, the other. It depends upon the project, the target environment, the specifications from the customer, the coding/development conventions of the software house, the mood you are in, the windspeed in the armpit of the Swiss Goshawk, how long the train was late this morning.....

uhhhh....yeah ok.....so i guess yoiur saying LIBs are better :-D

>>> yoiur saying LIBs are better

No, I'm saying sometimes they are better, other times .dll's are better.

If you are supplying a system to a customer who wants to write their own code to use parts of it, they will have specified in the contract whethger they want to do this with a statically linked library or a .dll. If you offer them something other than they want, then you will not get the contract.

There are many reasons for choosing one or the other, none are as simple as they may appear.

ok, im gonna let that one go. i was being sarcastic. i know its hard to spot. but thats what i was being. trying to crack a smile on someones face. thats all. i understood every word you said. and quite frankly, i like the both. sorry.