my editor project

[NoCforMe]

It might be a better way then to keep trying to reinvent the wheel.

But reinventing the wheel is so much fun! There are elliptical wheels, geodesic wheels, wheels of fire, all kinds of wheels.

[zedd151]

I feel like I've been on a hamster wheel these last couple weeks. 
Oh, it's only been about a week. Felt like much longer

[zedd151]

Anyway, I've been thinking about getting together all the code I need and creating a script to automatically create the entire editor project. I have only used the scripting engine in qeditor once, but what I have seen recently I know it is more powerful than I thought. The idea of using code that is already out there is to speed up the process. And there is more 64 bit code for this type of editor available, than for 32 bit. So I might bite the bullet and take another dive into 64... 


It might just be the case that I need to take a break from my editor project for a while. We'll see how I feel about it in a coupla days.

[NoCforMe]

[...] creating a script to automatically create the entire editor project.

I don't get it; how would that work? This is different from, say, a batch file that assembles and links the project?

Or are you thinking of a "sorcerer's apprentice" that would somehow ... code the project for you? Kind of like Mickey Mouse in "Fantasia", with all those brooms? That could be interesting ...

[zedd151]

The script contains everything needed to create an entire project, including resources. You should check it out. I'm sure there are help files in the masm32/64 SDK for using the scripting engine. I'm not at my computer else I'd check that. It is harder to explain than seeing what it does by using it. You should give it a whirl.
Give me a few minutes to go back inside and I'll post some more information about it...

[zedd151]

for NoCforMe:
In the Masm64 directory,
In tEditor (64) bit, on the menu bar is "Code"
There is a menu item "Full Edit" that creates an editor(64 bit) with the usual functions found in most editors - using a script for the scripting engine. Clicking on "Full Edit" invokes the scripting engine to process "fulledit.qse" (found in scripts folder)
Make a folder somewhere and put a name on it. Then when the script engine asks for a folder direct it to that folder.
Then choose a project name (don't use spaces in the name - hutch says that will be fixed later)
It will create everything for the project, then assemble,links it (assuming no spaces).
Even if it doesnt assemble it, due to spaces in the name it still creates the project.
The batch file has an error in that there aren't quotes around the project name in the batch file so will have to be added manually. Or simply use any editor and look at the script(*.qse) to see how the code, data and resources are handled.


In Help, there is qeditor help. In there is 'Scripting' that explains how to use the scripting engine in qeditor to write scripts for the scripting engine. I am unsure if tEditor uses the same script engine though, as qeditor. You can ask hutch about that.


"Full Edit 64 bit editor" project attached. NOT my editor, but an example from the Masm64 SDK.
I removed attachment as it has served its intended purpose. If you would like to see it, follow the directions above re: "Full Edit" .

[daydreamer]

It might be a better way then to keep trying to reinvent the wheel.

But reinventing the wheel is so much fun! There are elliptical wheels, geodesic wheels, wheels of fire, all kinds of wheels.

Best to invent wheel of fortune that makes you rich 
Zedd scripted creation of program could be made by asm+template + use catstr in several places ,texts got from several edit boxes asking user to fill class,project, names and width and height

[zedd151]

Zedd scripted creation of program could be made by asm+template + use catstr in several places ,texts got from several edit boxes asking user to fill class,project, names and width and height

With the integrated script engine in qeditor and tEditor it is easier than that. Well, creating the script itself is a little more involved. But once done writing the project to file is eezy peezy. Just select a folder where to put it and a project name.
I'm going to put the current 'my editor project' on hold while I play with investigating using the script engine and creating some scripts for it. I will most likely create a thread if I do anything worthwhile with it.

I did something more similar to what you described Magnus, for the plugin builder. User chooses a name for the plugin and the plugin builder concatenates strings for making the batch file to assemble & link the code to produce the plugin dll then copy the plugin to /Masm32/plugins. A similar method for inserting the user defined plugin code into the .asm file for the plugin.


Well I'm off to experiment with writing scripts. Seems not a lot of documentation for it... I can learn some things by examining the scripts that are part of both Masm32 and Masm64 SDK's though. 

[zedd151]

Right now I'm dabbling in 64 bit code again, so this project is on indefinite hiatus in the meantime. There is only one of two possible results of this.
1. I give up on 64 bit assembly and continue here where I left off with this editor project ... 
2. I continue my 64 bit journey and write an editor in 64 bit, with very much the same functions that I proposed for this editor. 


The last version of this editor can be found at   http://masm32.com/board/index.php?topic=10411.msg114638#msg114638

[NoCforMe]

I don't understand; why do you even want to mess with 64-bit? So far as I can tell, it's complete overkill for 99% of most projects, unless you're doing some kind of extreme number-crunching supercomputer work.

[zedd151]

I don't understand; why do you even want to mess with 64-bit?

For practice and a change of pace. 

[jj2007]

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


Good idea, but the ret costs quite a number of bytes. Here is a slightly shorter alternative:

Code: [Select]

WndProc proc uses esi edi ebx hWnd, uMsg, wParam:WPARAM, lParam:LPARAM
  Switch_ uMsg
  ...
  Case_ WM_CLOSE ; decide whether to close or not
.if UnSaved
MsgBox 0, "Sure to close?", "You have changes:", MB_YESNO
sub eax, IDNO ; typically, this box should only be used if there is unsaved content
.if Zero?
pop edx ; balance the stack (see Switch_ documentation)
jmp @RetTrue ; return eax, in this case zero (i.e. refuse to close)
.endif
  .endif
  Case_ WM_NULL
jmp @RetNull
  Endsw_
  invoke DefWindowProc, hWnd, uMsg, wParam, lParam ; default processing
@@:
  ret

@RetNull:
  xor eax, eax
  jmp short @B

@RetTrue:
  or eax, -1
  jmp short @B
WndProc endp
2 x jmp @B is 10 bytes shorter than 2 x ret

[NoCforMe]

Good idea, but the ret costs quite a number of bytes.

Oh, come on, JJ, get real: here's now many bytes a RET costs:

Code: [Select]

0040114A  . C9             LEAVE
0040114B  . C2 1000        RET 10

4 bytes. You're really going to obsess over that, in a program that's typically many tens of K bytes?

[jj2007]

Does that mean that you typically don't preserve esi, edi and ebx?

Code: [Select]

@@:
    pop ebx
    pop edi
    pop esi
    leave
    retn 10
@RetNull:
    xor eax, eax
    pop ebx
    pop edi
    pop esi
    leave
    retn 10
@RetTrue:
    or eax, FFFFFFFF
    pop ebx
    pop edi
    pop esi
    leave
    retn 10

[NoCforMe]

Yes, I do like Zedd; I explicitly push/pop them when I need to use them, confining that to a small section of the code.

Code: [Select]

; Give the text a nice left margin:
PUSH ESI
PUSH EDI
LEA ESI, [EBX].DRAWITEMSTRUCT.rcItem ;Copy the DRAWITEMSTRUCT RECT
LEA EDI, gpRect ;  to our local one.
MOV ECX, SIZEOF RECT
REP MOVSB
POP EDI
POP ESI

I never use "USES". So I have a pretty good idea of what's going on "under the hood" with my subroutines.