Another ASM editor

[hutch--]

Hi David,

Works fine here, the font is a bit small for my eyesight but its clean and clear. It will be interesting when you get more of it done.

[jj2007]

JJ, I smallerized it so it might fit your screen; your advice about getting the monitor work area is good, but it was all I could do at this point to make it resize reasonably. (You'll notice that you can shrink it vertically so that the listbox on the right disappears; not good.)

Works fine now

[NoCforMe]

Hutch--sorry 'bout that. I guess I need to work on the "adaptive" version for those with less than eagle-eye vision. (Kinda just joking, actually. Probably won't happen.)

[NoCforMe]

So, idea: What would you think about an editor, such as mine here, that would be configurable by the user? I'm thinking about all those dingleberries I put in there, all the "inserts" you can use. Obviously they're tailored to the way I program, which is certainly not the way everyone else does. I was thinking about making a configuration editor that would let you put in the items you want to use. They could be stored in a text file and loaded with the editor. Would that be worth doing?

The only things that probably couldn't be configured are the "editable items", like PUSH/POP which have specific dialogs to deal with their editable elements (like choosing the register). Everything else could be done, though.

[hutch--]

David,

What I do in both of my editors, QE and the new 64 bit one is to write a couple of settings files, one for binary and the other for test and between them you can store a lot of settings. I would recommend avoiding the registry as you lose portability if you put settings in the registry. It makes sense to put the settings files in the same directory as the editor as you can routinely keep track of them when the editor is started from other directories or drives.

Simple programmable menus are easy enough to do but complex ones that start multiple file types are nightmares to code and you have to build it into the editors base architecture. It can be done but its a lot of work and even more testing.

[TimoVJL]

Local ini-files are usable in network usage, as they can share predefined paths and settings.
My previous life factory used programs from local network and nothing didn't installed for user / user group / working point ...
It was always easy to make a local copy of program or shortcut with own settings.

[NoCforMe]

Oh, I know how to do this. Planning on it, actually. The configuration file (a plain text file, naturally, not binary, so easily edited) will reside in the same folder as the executable. The executable will locate the file by getting its home folder (using GetModuleFileName() ), read it and populate its internal structures.

I'm even going to have a built-in configuration editor in the program so you don't have to edit the config file. Write the values to the config file (mostly text strings). I've done this before, and it works well.

[jj2007]

For inspiration

[NoCforMe]

My preferred format for this type of file is

configItem = configValue

Easily parsed and edited.

Sections can be headed by

[sectionName]

[TimoVJL]

Useful API functions
WritePrivateProfileString

[jj2007]

My preferred format for this type of file is

configItem = configValue

Easily parsed and edited.

Sections can be headed by

[sectionName]

Not so far from my format ;-)

Code Select Expand

*** The first line can be edited manually ***
crtDate=06.09.2022
crtTime=23:41:46
modTime=06.09.2022, 23:44:20 ; this is the time of the last modification

I haven't thought of the [sections], though (you can add them manually, of course). Apart from readability, are their other good reasons to have them?

[NoCforMe]

Yes, and it's not because of readability, and it's also why I can't use the suggested Write/GetPrivateProfileString(): there will be sections, and within these sections multiple items with the same subsection heading, like so:

Code Select Expand


[inserts]
[insert]
displayText="PUSH/POP"
insertText= [expanded form that'll get inserted]

[insert]
displayText="CreateFileEx"
insertText= [expanded form]

etc. ...


I could just have pairs of strings (display/insert), but I prefer to make it a bit more formal and have a subheading for them. Easy to do in any case.

I've also done this in the past:

Code Select Expand


[inserts]
insert (
displayText="PUSH/POP"
insertText="<expanded text>"
)
insert (
dsplayText="CreateWindowEx"
insertText="<expanded text>"
)

etc. ...


but I think I'll make it a bit simpler this time. After all, this isn't really a programming language.

I've been creating and parsing such files since the 1980s, so it's not difficult for me.

For an .ini file I could use the form you suggested. This is a .cfg file, not an .ini file. (The .ini will have stuff like the last window size, the selected font, etc.)

Oh, and of course because this is an ASM tool, all comments in my config/initialization files are preceded by ';'.

[HSE]

Code Select Expand


[inserts]
[insert]
displayText="PUSH/POP"
insertText= [expanded form that'll get inserted]

[insert]
displayText="CreateFileEx"
insertText= [expanded form]

etc. ...


Look like JSON could be a good format.

[jj2007]

This is a .cfg file, not an .ini file.

Do you have an example where cfg and ini behave differently?

[NoCforMe]

Yes, my own software.

Config files are for user-configurable stuff; in the case of this editor, it's (most of) the content of the "tool list" on the right, mostly insertable text. For instance, if you click on "CreateFileEx", you get a template for that function. The "goodies" dialog has a bunch more stuff.

Initialization files are for stuff used internally by the program: window size, selected font, etc.