News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Another ASM editor

Started by NoCforMe, September 03, 2022, 06:54:23 AM

Previous topic - Next topic

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

Quote from: NoCforMe on September 05, 2022, 04:06:35 PMJJ, 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 :thumbsup:

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.)
Assembly language programming should be fun. That's why I do it.

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.
Assembly language programming should be fun. That's why I do it.

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.
May the source be with you

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.
Assembly language programming should be fun. That's why I do it.


NoCforMe

My preferred format for this type of file is

configItem = configValue

Easily parsed and edited.

Sections can be headed by

[sectionName]
Assembly language programming should be fun. That's why I do it.

TimoVJL

May the source be with you

jj2007

Quote from: NoCforMe on September 07, 2022, 05:58:52 AM
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 ;-)

*** 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:


[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:


[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 ';'.
Assembly language programming should be fun. That's why I do it.

HSE

Quote from: NoCforMe on September 07, 2022, 08:21:04 AM

[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.
Equations in Assembly: SmplMath

jj2007

Quote from: NoCforMe on September 07, 2022, 08:21:04 AMThis 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.
Assembly language programming should be fun. That's why I do it.