Another ASM editor

[HSE]

Font color don't work

I've put in no such options.

... then somebody else do that 

[NoCforMe]

Well, again, what colors do you want changed? I assume you mean the edit window, right? I could do that pretty easily.

[HSE]

Well, again, what colors do you want changed?

I don't want nothing. Just taking a look to what you are doing. 

[jj2007]

you're actually using the RichEdit control to store them

Yes, that's the trick: a hidden 3-character code consisting of two "magic" chars plus one indicating the length of the bookmark text:

°B1Init

Add the constant 3 to 1 to obtain 4 chars, i.e. Init

It would be easy to implement for plain text asm files, if on loading the file you hide these codes, and on building a source you send only the visible text to the batch file. However, the source would look strange in QEditor, so exchanging sources would require an "export without bookmarks" option.

A difficult choice, but I swear I couldn't live without bookmarks. For hello world proggies, you don't need them, of course, but beyond a thousand lines they are a must

[NoCforMe]

So for my editor, which now uses an ANSI RichEdit control, if I switched to the Unicode flavor, could I still deal just with ANSI text so far as loading and saving files goes? If I put in those special characters, would they be invisible in the edit window?

[jj2007]

Yes and yes

[NoCforMe]

I was going to hold off on this, but I put a kewl new feature into EdAsm, plus fixed a tiny but annoying problem, so I wanted to get this out there.

The feature is in the "extra file" viewer. Use the menu button, Ctrl-E or the menu to open a file to view. Pick a non-ASCII file.

The problem: for a while now I've noticed that the app seems to creep towards the right side of the screen; I found myself getting irritated and resizing the window without really thinking about it. Well, today I definitely noticed that happening, so I closed the app, looked at the window X- and Y-positions in the .ini file, fired it up again, closed it again, looked at the .ini: sure enough, those positions were being incremented by 1 every time! (The positions written to the .ini file come from GetWindowRect() at the time the program exits, which of course were both +1.)

Turns out the problem was in this code after creating all the windows but before entering the message loop:

Code Select Expand


; Make main window recalculate its size taking all controls into account:
cfgOK: MOV EAX, MainWindowW
INC EAX
MOV EDX, MainWindowH
INC EDX
INVOKE SetWindowPos, MainWinHandle, NULL, 0, 0, EAX, EDX, SWP_NOMOVE


The reason for that (incrementing X and Y) was to force a resize of everything (through WM_SIZE), otherwise the edit window didn't cover all the area it should unless you (the user) manually resized the window. That's been working, but the side effect is that the main window grows by (1,1) every time you use the program. Not good.

I fixed it by adding this:

Code Select Expand


; Make main window recalculate its size taking all controls into account:
cfgOK: MOV EAX, MainWindowW
INC EAX
MOV EDX, MainWindowH
INC EDX
INVOKE SetWindowPos, MainWinHandle, NULL, 0, 0, EAX, EDX, SWP_NOMOVE

; Need to hit that again (above code was causing window-size "creep" in .ini file):
INVOKE SetWindowPos, MainWinHandle, NULL, 0, 0, MainWindowW, MainWindowH, SWP_NOMOVE


hitting it again with SetWindowPos(), this time with the original size. It works, but it's obviously a kluge and a waste of a Win32 API call. What's happening it that things aren't getting sized properly in the first place, before WM_SIZE is issued. I need to go back and find out what's really wrong and fix it. Someday.

[jj2007]

force a resize of everything (through WM_SIZE)

That sounds odd, I can't remember having seen that. Normally, you receive at least two WM_SIZE messages very early in the process:

Code Select Expand

        #  wParam   lParam      uMsg
msg     10  00670001 02D80FF4   WM_SIZE
msg     31  00000000 00CA025E   WM_SIZE

Discard the first one (1=SIZE_MINIMIZED). The second one (0=SIZE_RESTORED) has width and height of the main window's client area, and that's the moment when you can adjust your child windows.

[NoCforMe]

Thanks, but I'm already doing that:

Code Select Expand


;==================================
; WM_SIZE handler:
;==================================

do_size:
CMP wParam, SIZE_MINIMIZED
JE zero_exit ;Skip resizing on minimization.


Any other ideas?

Dang. As soon as I posted that I saw the problem, why it didn't work. Going to fix it and try it out now.

[later] Tried it, didn't work. I changed the test for minimized to

Code Select Expand


CMP WORD PTR wParam, SIZE_MINIMIZED


but only because I got scared after seeing the value you showed for WM_SIZE(wParam), which was 00670001. Which makes no sense, since according to MSDN (I'm sorry, "Microsoft Learn" these days), wParam is "The type of resizing requested. This parameter can be one of the following values:". Says nothing about a high word and a low word. So where does that "0067" come from?

In any case, didn't work even after looking for the real SIZE_MINIMIZED. So for now I'm not going to sweat it and let my kluge-y fix alone.

So did you try my new feature?

[NoCforMe]

Well, I fixed my resizing problem by an elegant, if a little sneaky, method: I created my main window with zero size (width=height=0). Then when WM_SIZE kicks in it is forced to resize, since the new size ≠ old size. Easy peasy.

[jj2007]

I got scared after seeing the value you showed for WM_SIZE(wParam), which was 00670001. Which makes no sense

Right, there is a glitch in my code, and wParam is indeed zero. Apologies

(I am currently fighting like hell with the buggy msftedit.dll...)

[NoCforMe]

Good luck with that.

[jj2007]

Yeah, it's about that big

RichMasm is now running more or less fine on Win7 with Sys32\msftedit.dll, but on Win10...
- with the Office12 dll, it hangs for one big (2.7 MB) source
- with the original Win10 msftedit.dll it works, but it loads very, very slowly
- with the Win7-64 msftedit.dll it works fine, a factor 5 (!) faster than the Win10 dll.

It's really a shame that Micros*t neglects the only control that is/should be able to use formatted text

I added an update to the Microsoft page

[NoCforMe]

So based on your experience, how would you judge Micro$oft's interest/alacrity in fixing problems running under Windows 7 (which is, after all, an officially obselete OS)?

I get a sense from reading Raymond Chen's blog that they (Microsoft) are not as callous and cavalier as many people make them out to be, that they really do have an interest in maintaining backwards compatibility, seeing as there's just so much "legacy" use of their software. How this actually translates into action is another question altogether.

(And of course today's news is that they just laid off 10,000 people, about 5% of their workforce.)

[jj2007]

Good question, David

What I see with the RichEdit control is that the team around Murray Sargent is working hard on adding new exotic features, such as LaTeX-style math display, but have little contact to users like us. They have a serious bug in the Win7 version? Nobody noticed, maybe. Or, other theory: they noticed and fixed the bug (dll size increased by factor 3, dll speed decreased by a factor 5) for Win10 but didn't bother to include it into a Win7 update.

There is an old saying: don't assume bad intentions if incompetence could be the cause