Another ASM editor

[jj2007]

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.

What I mean, David, is: what is the difference when working with them?

Wiki ini file:

Code: [Select]

; last modified 1 April 2001 by John Doe
[owner]
name = John Doe
organization = Acme Widgets Inc.

[database]
; use IP address in case network name resolution is not working
server = 192.0.2.62     
port = 143
file = "payroll.dat"
Wiki cfg file:

Code: [Select]

DOS=HIGH,UMB
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE RAM
DEVICEHIGH=C:\DOS\ANSI.SYS
FILES=30
SHELL=C:\DOS\COMMAND.COM C:\DOS /E:512 /P
The ini file has the [owner] and [database] sections, but apart from this minor detail, I can't see a difference, format-wise.

See also the formats table here, comparing various config file formats.

[hutch--]

David,

While putting strings into a text file makes sense, rather than have to convert numbers both ways, having a structure of your own design with as many numbers as you wish to preserve as structure members is fast to load, save and internally process. This is why I use a binary file for numbers that must be preserved.

[NoCforMe]

What I mean, David, is: what is the difference when working with them?

The ini file has the [owner] and [database] sections, but apart from this minor detail, I can't see a difference, format-wise.

No, you're right: format-wise they're very similar. Can use most of the same parsing code.

[NoCforMe]

While putting strings into a text file makes sense, rather than have to convert numbers both ways, having a structure of your own design with as many numbers as you wish to preserve as structure members is fast to load, save and internally process. This is why I use a binary file for numbers that must be preserved.

Thanks for the suggestion. Since it's so trivially easy to convert numbers either way, I prefer to use plain text. Conversion time isn't an issue (for me, anyhow). But I'm sure your way would work well for someone in a different situation.

[TimoVJL]

Since it's so trivially easy to convert numbers either way, I prefer to use plain text.

With Windows native ini-files
GetPrivateProfileInt

[NoCforMe]

Here's the latest and greatest, for anyone who's still following this project.

This version is fully configurable by the user, at least so far as the items in that listbox (the "tool list", I call it) goes. There's an attached configuration file that's read on startup; the tool list is populated from this file. All seems to work well at this point. I'll be posting some source code soon.

There are 3 sections to the tool list:

• "[Inserts]" (click on the listbox item and that item gets inserted into the edit text)
• "[Goodies]" (click on the "Goodies" listbox item and a dialog opens; click on any item in the mcListbox* control to select it.
• "[Cubbyholes]": hold text for copying/pasting/searching

The sections can be arranged in any order, so you can have the "cubbyholes" where you prefer them. Currently the listbox doesn't scroll; that's coming soon, to be able to handle a long list.

Currently you can copy and paste. Search is not yet implemented. (That'll happen when I switch to a RichEdit control.) Select text, click one of the "C" buttons to copy text to the cubbyhole; click the "P" button to paste that text. (This is separate from the edit control's cut/copy/paste functionality, which works as well.)

You need to have the config file in the same folder as the program (the program should find it wherever you run it from). If there's a parsing error, only the cubbyholes will be created. You can play around with the config file, add the items you like (there's a text file explaining the config file format, which is pretty simple).

I'm particularly happy with my parser here: it's robust, simple (no spaghetti tangle of conditionals & jumps), and handles text well: it preserves the content of your "insert" text: CR, LF, tabs all come through. Allows embedded quotation marks in text (use double double-quotes, like "This ""text"" has embedded quotes"). And it allows comments! (starting with ';', since it's an ASM editor).

* The mcListbox (multi-column listbox) is my custom control used in the Goodies dialog. Still under development but works well.

[jj2007]

Works fine

- What's the difference between inserts and goodies? I can't see any...
- The exit dialogue is dangerous. In RichMasm, I use "Save changes?", with Yes (default), No, and Cancel. Given that the exit/close key is VK_ESCAPE, and an Escape in that dialog means Cancel, it has never ever failed me: You need to say explicitly NO to lose your data.

My 2cts ;-)

[NoCforMe]

- What's the difference between inserts and goodies? I can't see any...

Basically their location. The idea is to put more commonly-used items in the listbox itself, and have numerous other items in the Goodies dialog. Otherwise you're right, they're just insert items.

- The exit dialogue is dangerous. In RichMasm, I use "Save changes?", with Yes (default), No, and Cancel. Given that the exit/close key is VK_ESCAPE, and an Escape in that dialog means Cancel, it has never ever failed me: You need to say explicitly NO to lose your data.

Good point. I was actually wondering about that as I was clicking "yes" on that dialog when testing.

[NoCforMe]

Yikes.

I tried adding a vertical scrollbar to the listbox, so you can have more stuff than will fit on-screen. What a disaster! Run the attached version and try scrolling and see what happens.

Anyone have any idea what's going on here? Keep in mind that the listbox has a lot of children (the cubbyhole buttons). But it should take care of them, right? If you click somewhere when the control looks all messed up it'll redraw itself correctly.

This looks unworkable to me, unfortunately.

[jj2007]

Yes, something is seriously messed up.

Btw C P I understand, but what are the ? and ? good for? Ok, fine

Re inserts & goodies, in RichMasm I have:
a) "fast inserts" like e.g. typing .rep<space>inc ecx
b) the AutoCode menu: one click to insert a piece of formatted code (your goodies require three clicks - too many for my taste)

Most of the time I use the typing. It's definitely faster, but one must memorise the shortcut.

[NoCforMe]

Search down and search up (currently unimplemented). That's where I was hoping to use that magnifying-glass character we were playing with before. Something that looks like "find".

[NoCforMe]

Regarding that horrible scrolling action, I guess I could consider handling scrolling myself, since I've already got the listbox subclassed. Maybe using ScrollWindowEx()? (Although isn't this what Windoze is already doing behind the scenes?) It has an option (SW_SCROLLCHILDREN) to scroll children along with the window.

[NoCforMe]

More weirdness; check out the attached .exe. Click on the scrollbar buttons (I'm only handing SB_LINEUP and SB_LINEDOWN) and watch the parade of buttons. I used the SW_SCROLLCHILDREN flag with ScrollWindowEx(), and boy does it scroll them children, but not the parent. Not quite what I had in mind.

Does anyone have a clue what's going on here, and how I could possibly scroll this control (listbox)? I can't be the only person in the world who ever tried to do this. Time to look on the interwebs (CodeGuru, Stack Overflow, etc.) I guess.

Here's an idea: all the trouble seems to be with those damned buttons; the listbox itself scrolls fine and dandy. So how about if I somehow intercept the listbox scroll messages and explicitly move the buttons by hand, hopefully synchronizing them with the listbox? It would be a pain in the butt, but could it work?
I've been thinking about this: if I could figure out how far the listbox has been scrolled, I could move all the buttons by that amount. But how do I know when and how far the listbox has been scrolled? WM_VSCROLL doesn't tell me that.

[jj2007]

Why are these buttons kids of a listbox? They should be independent controls imho...

[NoCforMe]

I don't think so, JJ, for a couple reasons: by making them children of the listbox, I can easily get all their messages (BN_CLICKED) through the (subclassed) listbox proc. (You don't even need to set BS_NOTIFY to get these.) Otherwise I'd have listen to all 16 or 20 buttons individually. Also, how would you move them, or even place them in the control to start with? No, I'm sure this is the right approach. It's just that scrolling that's a problem.