I have been checking code that has recently been reported as problematic in this forum in Quick Editor and both instances are related to using SendMessage with EM_GETLINE.

On my win95b, win98se and winNT4 + sp6a, the API call works as it is documented but i have no immediate way of testing what is happening on XP.

If anyone is using Qeditor on XP, would you test if the Auto Indent works properly and if the setini.exe application that is called when you change editor settings works correctly when you press the "Check Menus" button ?

I need to see if this is normal on XP or unusual.

Regards,

hutch@movsd.com
Posted on 2002-06-01 08:25:40 by hutch--
Auto Indent = No Problem.
Check Menus = Endless loop of message boxes.
Posted on 2002-06-01 09:08:40 by bitRAKE
Ricky,

Thanks for testing this, this one is no so much of a problem to fix.

Regards,

hutch@movsd.com
Posted on 2002-06-01 11:52:16 by hutch--
I have tested it on XP, and there?s something going on with the indent: when I?m editing someting, it "shifts" the indent thing, Mostly evewry time I write a label, like:

pop this
pop that
jmp over_this
over_this: <----------Here the disp`lay moves
femms <-----here moves back


It?s the only thing I?ve found yet.
By the way, I use it to code.
(Wish the fonts could be changed though)

I like it, with the grown up editor ;) too.
Posted on 2002-06-10 14:32:20 by slop
fjrp2,

Thanks for your feedback, it seems that all of the problems associated with qeditor come back to the EM_GETLINE message sent with SendMessage specifically on XP as it works correctly and to the documentation on win95/98/NT4/2k.

It seems specific to XP that the richedit 1 control does not perform to the previous documentation so I am currently writing a complex test piece as an editor to try and track down what the variations are so I can find another work around for errant API functions.

Regards,

hutch@movsd.com
Posted on 2002-06-11 00:56:57 by hutch--
Do you think that?s the only "different" thing with the XP API, or are there other "surprises" (should wue call them enhancements) ?
Posted on 2002-06-12 02:40:34 by slop
sloppy, most of the time things that seem like "hey, this windows
version does this thing differently" is when you don't follow the
specifications... it can be very subtle things, like the EM_GETLINE
documentation saying

Before sending the message, set the first word of this buffer to the size, in TCHARs, of the buffer.

Note that TCHAR is capital and bold, while 'word' is neither... thus,
this most likely refers to machine-word size (32bit), and not the
win32 16bit WORD datatype. I played around a bit, and while
"random" values don't produce any errors (as long as you don't get
buffer overflows), you definitely have to set this (d)word. Set it to
zero (or forget setting it, with zero-initialized allocated memory), and
you will get no string back.

There have been other cases where microsoft has been blamed for
programming errors that weren't theirs - I remember some memory mapping
issues... the behaviour of UnmapViewOfFile was definitely a bit
peculiar, and it ought to have returned error rather than doing
what it did. But the bug was still within hutches code, no windows.

This is not meant as 'hutch bashing' - but I'd just like to suggest
people to blame their own code before blaming MS. Most of the time,
it's your fault. I assume EM_GETLINE is widely used, there's
a lot of richedit applications out there... yet "EM_GETLINE+bug"
on google doesn't return anything that would indicate a but in ms code.

Hutch, assuming you don't store the buffer length in the first
dword of your buffers before EM_GETLINE, could you please try doing
this (even if you have a workaround already)? It would be nice to
find out if this really *is* a bug in MS code (though I doubt it).
Posted on 2002-08-02 11:47:34 by f0dder
Hmmmm,

recycled IRC. The message EM_GETLINE has been around since win95oem so the assumptions appropriate to what may work on XP or win2k don't mean much.

When Microsoft publish the specifications of a function and their own implementation of it differs from the documentation in one or more versions, I call it a BUG.


EM_GETLINE
wParam = (WPARAM) line; // line number to retrieve
lParam = (LPARAM) (LPCSTR) lpch; // address of buffer for line

WIN32.HLP
The first word of the buffer specifies the maximum number of characters that can be copied to the buffer.

MSDN
The first word of the buffer specifies the maximum number of characters that can be copied to the buffer.

Note that in two of the major references to Microsoft functions that there is NO reference to the information you quoted.


Before sending the message, set the first word of this buffer to the size, in TCHARs, of the buffer.


Which leads to my original point, the documentation for the function differs from the implementation in some windows versions. Now it does not matter if the function actually works in the Windows versions that differ, the problem is that they don't work in the way that they are documented.

Producing later documentation that has a different explanation only proves that the functionality has changed and that the function does not perform to the earlier specification that is documented in the standard Microsoft literature.

You need to keep in mind that EM_GETLINE is used with the 16 bit edit control that is in win9x, NT4, etc .... so the assumption that using the machines native "word" size is documented behaviour does not make sense. The 16 bit edit control cannot address.

I have to go at the moment but I will finish this later.

Regards,
hutch@movsd.com
Posted on 2002-08-03 02:51:45 by hutch--

Note that in two of the major references to Microsoft functions that there is NO reference to the information you quoted.

The november 2001 release of the PlatformSDK does. So does the august 2001.


You need to keep in mind that EM_GETLINE is used with the 16 bit edit control that is in win9x, NT4, etc .... so the assumption that using the machines native "word" size is documented behaviour does not make sense. The 16 bit edit control cannot address.

Well... even win32.hlp seems rather consistant in writing data types in UPPERCASE BOLD. Like PlatformSDK, it doesn't do this for the 'word' in EM_GETLINE. C code I have seen (both 16 and 32bit) use something like


*((int *) buffer) = buflen;

This seems to work just fine, and I've never seen anybody else complain about EM_GETLINE. Assuming that it is really a 16bit WORD that's wanted (which could be the case - there's a lot of win32 api documentation, and missing a little detail like uppercasing+bolding a couple words here and there could certainl happen), it will not matter since x86 is little-endian (well, it could matter if you have a ridiculously small buffer ;)).

If you can give a piece of code which has a reproducible EM_GETLINE problem, or you can give some information on how to make qeditor bork, I'd be happy to take a further look into this. I still very much doubt that it's a microsoft problem, but if it is, the exact circumstances of the b0rking should be identified (windows version(s), riched version(s), etc) so people can avoid problems with their code. But still, taking into account the amount of applications using richedit, and the lack of mention about EM_GETLINE trouble outside of wine mailing lists...
Posted on 2002-08-03 04:31:01 by f0dder
Right,

I am back, just rescued a damsel in distress. :)

You latest post makes the point about unreliable documentation in an operating system that has changed the operation of a function.

The november 2001 release of the PlatformSDK does. So does the august 2001.

Window in 32 bit has been released since 1995 and the documentation that was current for it then and later is different to the documentation you have quoted.

When changed code causes an existing function to break using the documentation that was current for it, its a BUG in the OS code.

Here is another, the function call "GlobalMemoryStatus" works as it is documented in win9x, WinNT4 but parts of it do not work in 2k/XP, I call that a BUG.

You mentioned a problem I had with the release call for a memory mapped file. When a function call causes a GP fault instead of returning the correct error as it is documented, I call that a BUG in the OS code.

The problem with your argument is that win32 existed well before the release of win2k and while win2k/XP have released additional functionality, it has also introduced BUGS in existing functionality because a number of functions that have been around since 1995 do not work any longer.

Now there may be the situation where the functions in Win2k work fine but I wonder what is the use when they deviate from the documented forms that have worked on earlier versions for a long time beforehand ?

We may have a different view as to what a bug in opereating system code may be. As I am well familiar with Microsofts habit of changing things without advising anyone and letting everyone find out the hard way that there are defects in one or more of the operating systems that they design.

I am yet to see your point in raising this issue when bad habits by Microsoft fill volumes. What I in fact did to solve the problem was to produce the functionality of EM_GETLINE by another method that did not suffer the defects of not performing to specification. It can be done with messages that are not shared with 16 bit controls and that appears so far to be more stable than the older messages.

I will keep using this technique until Microsoft changes the rules again and I will probably have to find another work around to another BUG that they introduce in a later version of Windows.

Regards,

hutch@movsd.com
Posted on 2002-08-03 05:43:04 by hutch--

Window in 32 bit has been released since 1995 and the documentation that was current for it then and later is different to the documentation you have quoted.

The text has been updated from win32.hlp to the recent platformsdk, but the content is still the same, really. The update has to do with unicode support (a thing that wasn't really in win3.x as far as I remember ;)).

win32.hlp says:

lpch
Value of lParam. Points to the buffer that receives a copy of the line. The first word of the buffer specifies the maximum number of characters that can be copied to the buffer.


PlatformSDK says:

lParam
Pointer to the buffer that receives a copy of the line. Before sending the message, set the first word of this buffer to the size, in TCHARs, of the buffer. For ANSI text, this is the number of bytes; for Unicode text, this is the number of characters. The size in the first word is overwritten by the copied line.


I don't see anything indicating changes other than the support of unicode text.


When changed code causes an existing function to break using the documentation that was current for it, its a BUG in the OS code.

Sure... but sometimes programmers have misinterpreted documentation (and that often because documentation has been poor). And other times the problems have been register preservation, structure alignment (etc) - things that aren't documented (or at least not with big bold letters), but still make a difference.


Here is another, the function call "GlobalMemoryStatus" works as it is documented in win9x, WinNT4 but parts of it do not work in 2k/XP, I call that a BUG.

Dunno, I don't have any trouble with it. Every field returned (on my win2ksp2 and a friends XP) has sensible values. I think you had trouble with "dwMemoryLoad" under NT4? That does sound like a bug, true. bazik had some negative values with pagefile size, but that's due to the int->str conversion routine. Unsigned, the value amounted to ~3.3GB, not a unreasonable size.


You mentioned a problem I had with the release call for a memory mapped file. When a function call causes a GP fault instead of returning the correct error as it is documented, I call that a BUG in the OS code.

Yes, it is indeed a bug of UnmapViewOfFile to unmap your main module with the value you passed to it (if you had been passing it your base address, it would have been correct behaviour though). But it still doesn't change the fact that *your* code was buggy and you blamed microsoft.


The problem with your argument is that win32 existed well before the release of win2k and while win2k/XP have released additional functionality, it has also introduced BUGS in existing functionality because a number of functions that have been around since 1995 do not work any longer.

I'm not saying microsoft hasn't made mistakes and introduced bugs in newer versions of their OSes... I haven't bumped into any yet, though (apart from UnmapViewOfFile not returning and error in your code). I think it's too easy to blame microsoft when something goes wrong. I still haven't excluded the possibility that EM_GETLINE *could* be broken, I just find it unlikely, and would like to be able to reproduce it myself.


We may have a different view as to what a bug in opereating system code may be.

Dunno. When something doesn't live up to the PlatformSDK information, I'd label it as either a bug or documentation error. But I try to be very very very sure that it's their fault and not mine before I rush out and say "yet another windows bug yadda yadda".

Bleh, this is turning into a flamewar. I just want a piece of code that shows the EM_GETLINE 'bug', or directions on how to make the old version of qeditor fail.
Posted on 2002-08-03 06:51:31 by f0dder
Well,

Since I did not resurect this topic for a free kick in something where you are a long way from being sure of the results you query, i wonder why you bothered ?

I have been shovelling through errors in Windows versions for about 12 years to date and sad to say its nothing new, its been happening that long. Win31wh.hlp was a lot better version than WIN32.HLP which takes a long time to decypher when you first get into it.

In days of old, when Microsoft made another mess of a function or a capacity, you could open the DLL code and see what it was actually doing and get the code to work properly but with the proliferation of Windows versions that are around and then the extra deviation with various service packs, getting something to work on one version does not help you on another, you are at the mercy of lousy documentation.

The problem was never that the code did not work, it was always related to the documentation of how it was supposed to work and these two categories do not always match.

I just dont see the point of your approach of defending badly written documentation that Microsoft are not willing to follow themselves in a later operating system version.

You may understand my approach of preferring operating system versions that Microsoft have abandoned as they are at last stable and you can predictably write code for them.

Fortunately most people in the world own out of date OS's so its not hard to cater for them where the later versions do suffer arbitrary changes that you find out the hard way when the code that works correctly on earlier version crashes on a later one.

I call these changes BUGS, with or without your agreement as I have seen thousands of them in my time, this is why I don't take much notice of what you say here as i have seen different too many times before.

Regards,

hutch@movsd.com
Posted on 2002-08-04 07:18:46 by hutch--
Just a slight bug with TheGun on XP with saving files. If I select "File -> Save" or "File -> Save As" from the menu the 'Open A File' dialog is always shown (After the 'Save File As' dialog if "File -> Save As" is selected). The saving of the file is still done correctly.
Posted on 2002-08-18 23:52:12 by huh
Huh,

Thanks for the info, I am trying to track this problem down on TheGun at the moment as it is working correctly on everything from win95 up to win2k fine but is showing the other file dialog as you have described on XP.

I am loading the dialog as per the Microsoft documentation using the correct structure etc ... but I do not have XP on a box anywhere and I am in no hurry to waste a computer loading it with XP.

Regards,

hutch@movsd.com
Posted on 2002-08-19 00:33:45 by hutch--
Hi hutch!

Now that the "DWORD" issue with QEDIT and Windows XP compatibility is solved, there is another funny thing that I find.
It doesn't happen with my 98 version, but when I try it on XP, it sometimes (haven't tested exactly when) doesn't load the file, it just opens in blamk, like when you press 'new instance'
That?s it, just to make you know.
Posted on 2002-08-19 11:02:09 by slop
Sloppy,

Thanks for the info, I have just about done the quirk that TheGun found in XP and when the testing is completed by an independent person I know with XP, I will post it.

I get really tired of messups with Microsoft OS versions and instead of wasting the time trying to debug what had happened, I just rewrote the dialog code to avoid whatever XP was doing.

Regards,

hutch@movsd.com
Posted on 2002-08-20 01:20:27 by hutch--
So then you rewrite the whole thing for XP?

Btw, just tryed The ne GUN and works fine.
Posted on 2002-08-20 12:36:51 by slop
Hi hutch

I too have experienced the problem with
Qeditor on WinXP.

When I am writing some code, suddenly the
text moves to the right, and later on back again.



One time, I have been giving my son my old, but
good monitor, later on, when I saw that the text
was moving right and left on Qeditor with my "new"
monitor, I thought that there was a little problem
with my monitor.
So I told my son, that I would switch our monitors back,
so that I could use Qeditor WITHOUT any problems....
Was I surprised, when I saw that the problem with
Qeditor WASN'T GONE.......:rolleyes:

Now I know, that it's "only" a matter of getting the code
right in Qeditor...
Posted on 2002-12-29 07:21:03 by The SharK
Shark,

Get the version from my web site, it is a full rewrite with additional capacity.

www.movsd.com

Regards,

hutch@movsd.com
Posted on 2002-12-29 17:29:22 by hutch--
Thanks hutch

I use the program all the time :alright:
Posted on 2002-12-30 05:42:41 by The SharK