my editor project

[zedd151]

Having some issues with the 'select_word' function hutch posted above. Not quite working as expected.

Alternative code here: Better word selection

Did you even read the post below that one? Work exactly as expected now.    As far as "Better word selection" be careful not to start a holy war with hutch.    There's usually more than one way to implement functions.

[zedd151]

... that handles also the uses esi edi ebx stuff, so it can cost several bytes more.

I never uses uses. I always explicitly push and pop my registers. It clutters the proc line otherwise. 

[zedd151]

After having a hard time making a function for word selection work the way I wanted it too, I finally have exactly the code needed for that (donated by hutch--). Thank you hutch.

I will be testing this latest version today to ensure no bugs have been introduced from various modifications, and finishing up some of the functions that are only partially implemented.

It's rather lonely in this sub board now, and there's an echo in here.    I noticed earlier today that mine is the sole topic here now.

Attachment 'basic editor11.zip' removed but is included in the archive In this post

[hutch--]

 

> It's rather lonely in this sub board now

At least your post is easy to find now. 

[zedd151]

At least your post is easy to find now. 

I only hope this board doesn't get downsized outtahere for lack of usage. 

[jj2007]

Did you even read the post below that one?

Of course not, why should I?

As far as "Better word selection" be careful not to start a holy war with hutch

"Better" refers to my own editor. If you had read my post, you would have understood that.

[zedd151]

"Better" refers to my own editor...

you didn't say that much in your post here, so it looked as if you were inferring better than the function discussed a few posts  above your post. But ok. 

[zedd151]

Put code in to parse the commandline to load a file dropped onto the programs icon.


Updated the attachment. Somehow the old 'tab replacement' code found its way in this version. 
Attachment 'basic editor12.zip' removed but is included in the archive In this post

[NoCforMe]

To save some space, I often use

Code: [Select]

    xor eax, eax
    jmp ReturnEax
...
    invoke CallWindowProc, ...
...
ReturnEax:
    ret

I go one better (or at least one different). In my window procs() I always have two exits that I can JMP to:

Code: [Select]

zero_exit:
XOR EAX, EAX
RET

true_exit:
MOV EAX, TRUE
RET


But the most important thing is, as I said, the rule:

Do not call DefWindowProc() or CallWindowProc() if you handle a message. Period.

[NoCforMe]

I never uses uses. I always explicitly push and pop my registers. It clutters the proc line otherwise. 

  Yes.

[zedd151]

I'm currently working on the search/replace dialog boxes. I may do something different though... details later. Also I looked at the tab replacement code in tEdit. If I can convert it for 32 bit operation I'll plunk that in here, replacing my unauthodox code. But looks like I'll have to convert some dependencies as well for that one. We'll see... I'll try to get one or the other into code for the editor today.

[NoCforMe]

How do you create dialogs? Do you use a resource editor?

I have another way of creating dialogs, my own homemade dialog editor that creates memory template files (include files) rather than resource files, thus not requiring the resource compiler, if you're interested. Works pretty well.

[zedd151]

How do you create dialogs? Do you use a resource editor?

I have another way of creating dialogs, my own homemade dialog editor that creates memory template files (include files) rather than resource files, thus not requiring the resource compiler, if you're interested. Works pretty well.

This
Now if I were to put code in to make an 'in memory dialog', I might as well make a child window instead. 

[zedd151]

We'll see... I'll try to get one or the other into code for the editor today.

Well that went over like a lead balloon. I got involved with something else, so nothing more yet for this editor.
...
I've been wondering if this project is even worth it. There are several options in the MASM 64 SDK for creating ascii editors, plus enough 64 bit code floating around to do almost everything I would want my next editor to do. I would only have to add my own custom functions of which I have the code already (in 32 bit) I'll sleep on this and decide in the morning.
Tonight I am going to piece all the code together that I can find to make a 64 bit editor; and see what code still needs to be added to that, to meet my needs. It might be a better way then to keep trying to reinvent the wheel.

[NoCforMe]

Now if I were to put code in to make an 'in memory dialog', I might as well make a child window instead. 

Kinda a joke, I know, but you kinda missed to point too: with my scheme, you don't have to create any windows. You invoke the dialog as you always do, except you use the DialogBoxIndirectParam() flavor, which instead of creating the dialog from a resource stored within the executable creates it from a memory template. Other than that, everything's handled by the dialog manager as usual. Easy peasy.