I've followed this tutorial on the Windows API, and would like to make a simple Notepad alternative, using the RTF control, in C. I have Borland C++ 4.52 installed, and downloaded a Win32 API Reference from Borland.

The problem is that I haven't been able to find out how to load a DLL and use its functions. Anyone know where I might find a guide to it?

Thanks in advance.

Basically there are 2 ways. You can let the linker do it, or you can do it yourself. To let the linker do it you'll have to link your program with a .lib file. In most cases the lib file has the same name as the dll. You'll have to link shell32.lib to use shell32.dll functions. Somewhere in your project settings you should be able to specify which libs to link.
The other way it to use LoadLibrary() to load a dll, and GetProcAddress() to import a function.
The downside of letting the linker do it is that your program will not load if the dll or one of the functions you need don't exist. (Unless you're using 'delayloaded dll's'), and that the dll is loaded when your executable loads, causing extra startup time, even when you probably don't need the function.
The downside of importing by hand is that it can be a lot of work, and is error prone. (It's easy to use the wrong prototyping, since the function is just a pointer.)

I'll need the DLL throughout the entire program, so I think it's best to use implicit linking. Yeah, I've read that you can use a .lib, but also that you can use a header file to expose the necessary functions.

My Borland C++ is old, though, and doesn't have libraries for riched32.dll or riched20.dll The Internet doesn't seem to have it, either.

You have to do both. The header is nessesary for the compiler to know the function names and prototyping, the .lib is for the linker to create the import table. A headerfile *can* contain some pragma to tell the linker which library to load.


You'll need the 'Microsoft Platform SDK' to get all header and library files. Unfortunately this is a 1GB+ download, and I'm afraid it will not be compatible with your compiler/linker. The oldest version which is still served by MS where I'm aware of is found here. 'Only' 340 MB. This version is compatible with VC++6.0, all later versions aren't. Maybe it's compatible with your tools.

Do you know that Borland has a new generation of free development tools? They're Back. I don't know if these run on W98.

Update: Some Googling took me to this site, which looks like the '98 PSDK. Maybe you've enough with iBLDENV.exe (build environment).

Thanks. There doesn't seem to be a Rich Edit Control library in iBLDENV, though. I looked in iCOM and iOTHER too, but they don't have any either.

According to Microsoft you can create a Rich Edit Control via CreateWindowEx. Then you have a window handle to send messages to. No need for function importing.

Interesting. Thanks! That helps a lot. Will toy around with it.

I got the code right, but the RichEdit control creation is failing. I really need that library and header file...

I would download the entire SDK if I had to, but my brother has been downloading way too much porn and watched too many YouTube movies, so our connection is capped.

The declarations are inside RichEdit.h, which you have. It's inside iBLDENV.Exe\WIN32-B.cab. This cab contains libraries too, but no RichEdit.lib. The header doesn't define any functions, so I suppose there isn't any library.
The creations fails. You mean CreateWindowEx returns 0? What does GetLastError() return?

Yeah. Belgium is famous for it's generous download limits.

I must not have looked well enough, because I even have a Richedit.h in my Borland installation, which is 1/3 the size of the one in the SDK.

Indeed, CreateWindowEx returns 0. So does GetLastError(), even after using the header files. I tried with both versions I got.

Here's the relevant code:


Really? Someone I know from the Netherlands didn't know until I talked about it recently.

I wouldn't mind the limit if it wasn't for my brother's download habits. There's enough for the rest of the household.

Also I think you need to either LoadLibrary(...) or do InitControl() before the RichEdit control is/can be created.

Man it's been years since I played with v4.52, I'm using MSVS2005 Pro now


MSVS 2005/2008 Express Edition is free from MS btw ... Just a Thought

Microsoft says you should call LoadLibrary() to determine which version of RichEdit is available. A side effect could be that the dll is loaded and the class registered.
I suppose you mean InitCommonControls()?


I don't think an edit control can have a menu. It should be in the parent frame. I would expect an error though.



That doesn't mix.

Right! ...It's been a while since I played with richedit controls, but I recall there being a simple way to load them, I just can't seem to find it in my old notes. I mainly do system utilities these days.

Zoiks! (missed that) I was thinking the target machine was 9x, not the developement machine.

Using InitCommonControls() generated an error that the function was not known. LoadLibrary("riched32.dll"); worked, though!

Thank you very much, both of you.

FYI: When you Google on a Win32 function, InitCommonControls() in this case, you'll find a hit in msdn2.microsoft.com. On this page you often can find which header and import library you need, commctrl.h and comctl32.lib in this case. So you should have included commctrl.h, making the compiler happy. Next to complain would have been the linker, which cannot resolve this function, so you should have linked comctl32.lib.

However, it seems to be not nessesary here. That's according to the documentation which says you'll only need InitCommonControls() when you want to use XP theme's in your rich edit. But on the other hand, it stated you'll only need to call LoadLibrary() to find out which version of rich edit you have, which seems to be untrue.

I did some Googling on this part and ran across a comment that if using MFC LoadLibrary is not required, if using pure Win32 API then LoadLibrary(...) is required.

Does that sound about right?

I haven't given up on this yet. In fact, I finally started on it. I've already got a basic notepad that can open and save files using the RichEdit control. That's the easy part, I guess.

your challenge is to make one better than TheGunn
http://www.movsd.com/thegun.htm

I can't do better than that. TheGun is coded in Microsoft Assembler, while I'm coding in C. No way I'll be able to make an alternative that small.

If anyone else is reading, I'm struggling to implement features. I have a Windows API reference, but it leaves some things to be desired. For most functions I need to allocate an array of chars that is big enough to contain the result. But I don't know how I would poll for the size needed.

You'll have to be a bit more specific. There are serveral different ways to get the needed buffer size. Sometimes there's you can provide a null-pointer in which case the function returns the needed buffersize. Sometimes there's a seperate function to ask for the needed buffersize. Sometimes the only way is polling. (Provide a buffer, and while the system tells it's not enough, enlarge it.)

For instance, the EM_GETSELTEXT message needs a buffer that is big enough to store the selected text in. Do I use the EM_EXGETSEL message, and calculate the size of the selection from that, or something?

Yes, AFAIK that is the most appropriate way. To ensure the buffer is big enough you could also use GetWindowTextLength(), since the selected text cannot be bigger than the total text. Of course this can be inefficient when you only want to copy a few bytes.
As you may have noticed, EM_GETSELTEXT is a dangerous function, since you can't provide the size of the buffer you're using. So I would avoid using it, and use a combination of EM_EXGETSEL and EM_GETTEXTRANGE

Great... My own application created a looping BSOD. I had to press Ctrl+Alt+Del to get out of it, which rebooted my system.

I'm trying to implement the Edit menu. But the way I did it is probably wrong. On MSDN it's totally different. Here's the code:

What I copy to the clipboard is random garbage. And sometimes it creates the aforementioned BSOD.

You can replace your code with just one WM_COPY. Although, if you're planning to support multiple clipboard formats (the right thing to do), i can't see a problem in your code. Except maybe RichEdit is not in ANSI mode?

Thanks, that worked! And it made it easy to also implement Cut, Paste, Clear and Undo. I also could implement Select All thanks to the experience I got earlier.

That'll do for now.

I still would like to know where my previous code went wrong, though.

Maybe cpMax is -1? In that case you alloc 0 bytes to contain all text.

When I tested my function, I never selected the entire range.

Next challenge is the Search dialog. I'll probably make it a resource.

I made a window with Resource Workshop. Problem is that even though the Windows platform target is Win32, it still looks like a Win 3.1 window. Eww. I'm guessing it's because of the compiler, Borland C++ 4.51, because the resource seems fine:

According to Wikipedia, version 4.52 is the first to support W95. That *could* mean that you are creating 16 bit software. When you are creating 32 bit software, look if you can target for Windows 4.0. (That should be a linker option). If you can't, try to add the DS_3DLOOK flag after STYLE.

I'm pretty sure I'm targeting Win32. Anyway, when I add the flag, it complains about an incomplete expression.

Is DS_3DLOOK included in your winuser.h? If not, the value should be 4.

Yes, it's defined as such. Weird.

Well, you can try to add 4 as flag.

Another approach: When it's a real 32 bits program, I suppose it's targetting NT3.51 (or maybe Win32s), but in any case windows 3.x. You can change the PE header to let it target window 4.0 (win95). The executable is the same, but windows will treat it different. The preferred way to change the header is to let the linker do it. For Borland 5.5 (which is free, by the way) you add -V4.0 to the linker command line. I don't know if this will work for 4.5 too.
The other way is editing the executable. You can use Stud_PE for that. Download it here, load your executable in it, click on 'Basic headers tree view in hexeditor' button, open 'Optional header', and edit Major- and MinorSubSystemVersion. (Beware, it's little-endian, so the major must be 0400, and the minor 0000.)

I edited the EXE, and now the Search dialog won't open anymore. In any case, major version was 0300 and the minor was 0A00. Bad Borland C++.

I'd like to get Visual Studio 6 on my PC, but I'm not sure if I can install it without IE. I've already read how to prevent the Java update, in any case.

Too bad. MS changed the dialog templates somewhere in the transition Win 3.x-4.x. Apperently you've got old-style resources in your project, and Windows seems not to accept that from a program targetting W4.0. Maybe your resource compiler (brcc32.exe?) can create newstyle resources. I've got two versions of Borland, 5.0 and 5.5. Both can create old and new style, but 5.0 defaults for old style, and 5.5 for new style.
The resource compilerflags are -16 and -32.

I really don't know if VS6 will install without IE. The interactive help will not work, because it relies on IE html engine. What about Vision Windows for BC++5.5?

Got Borland C++ Compiler 5.5 after jumping through registration hoops. And then I found out that Visual Windows has a version with it included. Oops.

Installed Visual Windows, and on start-up it complains about missing KERNEL32.DLL:GetLongPathNameW in a MSVC 8.0 DLL. So the website lies!

I managed to compile my resource and my program with the command line tools. But now no dialog works! Not my own, nor an open or save as dialog.

I've tried leaving out the resource. Doesn't make any difference.

What's also weird is that the size of the exe output by the compiler is 50 kB, versus the 29 kB one output by Borland C++ 4.52.

The problems keep piling up. I now added the path to the bin directory to the path environment variable, and whenever I try to compile now I get "Response file not allowed here.". Google doesn't have anything to say about that.

The examples of theForger don't show open/save dialogs either. I ran Dependency Walker on one of them, and it looks for Borland32 in KERNEL32.DLL. It's the same thing with my compiled program. This is weird.

I put some MessageBox calls in WM_COMMAND to figure out if these things were even getting called. Turns out they do.

As for the size, Borland C++ 4.52 uses the Borland C++ runtime to achieve a smaller size. I noticed this by using Dependency Walker.

The open and save dialogs work now! I looked at the page of theForger's tutorial that dealed with them, and it looks like I needed to use OPENFILENAME_SIZE_VERSION_400 instead of sizeof(ofn) when specifying the size of the OPENFILENAME struct. Whew!

My search dialog still isn't working, though. What's more, it only works in my program compiled with Borland C++ 4.52 when the IDE is running! Crazy stuff.

All right! I got my search dialog to work! Here's what I did. I changed the CONTROLs that were defined as checkboxes to CHECKBOX, and the CONTROLs defined as radio buttons to RADIOBUTTON.

I forgot to change DIALOG to DIALOGEX, it seems, but it worked either way. Yay!

Glad you sorted it. Welcome in the wunderful world of real Win4.0 targeting programmers.

/Edit: You're right about Visual Windows. The site doesn't claim W95 as beeing supported, but it says VW is developed using VC6, in which case msvcr80.dl
l wouldn't be used. You can try to use an hexeditor (or maybe Stud_PE) to edit msvcr80.dll. Change GetLongPathNameW in GetFileType. When you're lucky GetLongPathName is never called, and when it is, GetFileType will return 0, (FILE_TYPE_
UNKNOWN) which is interpreted as 'No long path name available for this particular file'. (I hope)

I'd rather not have MSVC8 DLLs at all on my machine. I'll get by without an IDE for now.

I implemented "Go To Line" and "Save"! Save was a bit tricky, since it involved a string, which always needs special treatment. I used a global string to keep the file name of the opened file, and I NULL the first char when I do "New". Seems to work well! I would have preferred to avoid using the string library, though.

Anyway, my notepad alternative is now good enough for basic editing, so I'll be using it to edit the program's own source code. How cool is that!

Next, Search and Replace!

I've been too lazy to do Search and Replace, so I've been doing other little things, like focusing the RichEdit, making it remember the file filter, and adding keyboard shortcuts.

Now I want to add a context menu. However, it's not working. I never receive a WM_CONTEXTMENU message when I right-click in the RichEdit. I've got all the rest figured out: call TrackPopupMenu with the menu handle using the parameters of the WM_CONTEXTMENU message.

Any ideas?

Does your editor have IME support? Or is it not that type of editor?

I remember when I tried creating a control with IME support. I went to hell and back twice, but managed to get a working code snippet in the end.

Dit you subclass the richedit?

IME? No, it's just a notepad.

I don't think I subclassed my RichEdit control, as I don't even know what that means.

EDIT: I looked it up after posting this message. However, my context menu still doesn't work. I don't seem to get the WM_CONTEXTMENU message either. I've verified that the new window procedure is called, though (which caused a stack error after lots of message boxes popping up...).

My code.

I did some research. You don't need to subclass for this purpose (and as you found it seems not to work). There are two ways to get the message:
1) Use SendMessage( hEdit, EM_SETEVENTMASK, 0, ENM_MOUSEEVENTS ). The parent will get a WM_NOTIFY/EN_MSGFILTER for all mouse events. Filter for WM_RBUTTONDOWN. http://msdn.microsoft.com/en-us/library/bb787974(VS.85).aspx
2) More powerful: Add some code to the messagepump to filter the WM_RBUTTONDOWN.

(BTW, your messagepump is not completely safe. Have a look here)
(BTW2, you know you can create menu's in a resourcefile and load/create them witch LoadMenu()?)

I don't follow... Notepad supports localized texts. AFAIK, on native systems, it supports IME. It doesn't seem to support 9x-style installed IME, though.

On the topic of subclassing, it simply means using:

Somewhere in initialization, creating a message proc with:

The applying it to your control using something like:


As for WM_CONTEXTMENU, you will need to forward WM_RBUTTONUP and WM_RBUTTONDOWN to DefWindowProc in order for the message to be generated. It may also be worthwhile to test if Shift+F10 works. This may also warrant for appropriate forwarding of messages.
For more details see this little bit of info on WM_CONTEXTMENU in RichEdit, and this description of WM_CONTEXTMENU.

Also, if you want, I can post my little code snippet for adding IME to a RichEdit control.

Thanks Mijzelf. I've taken approach 2. It seems to be the most efficient. I've also improved my message loop.

Now how can I have the context menu appear with the top left corner on the place my mouse is pointing at? It appears either above or to the left now.

The RichEdit control has some weird behaviour. It doesn't show the horizontal scroll bar until I start typing. All the appropriate flags are set, though.


Yes. Would this be more efficient?

Don't know what to make of this IME stuff. As far as I know, on Win9x, it's an IE module.

Refreshed source file.

If you ask me, placing message handling of a specific control in the main message loop is just plain wrong. It's the sort of hacking you'd expect a Mac-developer to do on Windows, "because it's not quite the same". Creating your own window proc is not that difficult, nor is setting it to your control.


It's available for Riched20.dll. I've noticed you're using Riched32.dll which is slightly different. Not sure if it works with 32.
At any rate, supporting IME is fairly simple. You just need to load up a small COM object which offers a TranslateMessage alternative (if loading fails, you just use the normal TranslateMessage), plus handling of WM_SETFOCUS and WM_KILLFOCUS in the RichEdit control.
It basically enables the creation of multi-byte characters with multiple key-strokes, for languages where 102-keys just doesn't quite cut it.

One more thing, if GetMessage returns "-1" then it's probably a good idea to leave the loop, not just destroy the window and keep going. After all, having already failed once, there's no reason to believe it would successfully return the WM_DESTROY or WM_QUIT which would be posted by a normal DestroyWindow. A "return -1;" or "throw;" may be more appropriate there.