Editor for testing

[jj2007]

I would be inclined on all of the different menus to write each language in itself, English for English, French for French etc ....

Done. It's indeed more logical :t

There are major changes under the hood, the exe works fine but the attached source will not build yet with the current MB version. To give an idea how the multilingual interface is organised, see \Masm32\MasmBasic\Res\GuiData\IdeData.tab in the last attachment. The tab format opens e.g. in Excel.

[hutch--]

This one looks a lot better, the language menu reads properly for each language. I would move the top of the main edit window up a little as it makes your toolbar strip look unbalanced (IE: top heavy). It should be easy enough to enable all of the edit menu options and it will start to look like a working editor. Is there some reason why the file open dialog lists the files out of order ?

[jj2007]

This one looks a lot better, the language menu reads properly for each language. I would move the top of the main edit window up a little as it makes your toolbar strip look unbalanced (IE: top heavy). ...
Is there some reason why the file open dialog lists the files out of order ?

I've moved it up some pixels. It's a bit of fiddling to get it working with different margins, see "m3" in line 1 of the source:

Code Select Expand

GuiParas equ x30, y30, w1280, h700, b RgbCol(160, 255, 200), m3 ; greenish background, margins 3px

The files are out of alphabetical order, yes. For decades, my preferred order has been "latest on top", for good reasons :P

Complete project attached; the files in the last two zips go to special folder \Masm32\MasmBasic\Res\GuiData (see the Rsrc sections at the end of the *.asc source); of interest is the *.tab file, which contains all the multi-language text.

Building requires MasmBasic version 22 December. I've tested it on Win7-64, XP and Win10. Works fine, except that in XP the "exotic" languages work for the menus and tooltips but not for the edit control :(

[hutch--]

Put this manifest file in the same directory as the editor and you will get the later appearance. Tested only on Win10.

With XP you may need to get the east Asian fonts to display Chinese and similar fonts.

[jj2007]

Put this manifest file in the same directory as the editor and you will get the later appearance. Tested only on Win10.

This looks identical to the manifest I am using. Can you see any difference? For me, toolbar, tooltips and menus look the same, independently of the manifest ::)

Code Select Expand

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<description>MasmBasic</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
/>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.GdiPlus"
version="1.0.0.0" processorArchitecture="*"
publicKeyToken="6595b64144ccf1df" language="*" />
</dependentAssembly>
</dependency>
</assembly>

[hutch--]

Look at the status bar and the dialog buttons. You can use RGB/A toolbar images and many of the controls look different. Its a Win2k interface versus an XP and later interface.

[jj2007]

Look at the status bar and the dialog buttons.

Absolutely no difference! I attach a version with no included manifest. With a SmallEditorNoManifest.exe.manifest in the same folder, it should look different, but it doesn't  :(

Btw here is an old thread (2013) treating manifests and visual styles. It ends without conclusions, it seems, but points to an interesting Geoff Chappell page on the behaviour of InitCommonControlsEx and the like. It's incredibly messy.

For example, I can't see any changes to my toolbar, MsgBox or statusbar behaviour, with or without manifest, with or without calling InitCommonControlsEx. However, even without manifest and InitCommonControlsEx, I get the latest crappy OpenFile control - the one with drop-down headers. Hutch noticed that files are "out of order", to which I replied that I like them sorted by date, latest versions on top. But where is my SmallEditor.asc of today, 22 December??? This box is sorted by "data", Italian for "date". But... try to solve the mystery... Windows has become so sick

Richmond coders, you should all be sacked for unimaginable dumbness :icon_redface:

[jj2007]

New version attached - the tooltips are working fine now :t

It took me several days to analyse this horrible mix of lousy documentation, misbehaving tools (rc.exe) and broken tooltips. In case you are interested, I attach also an old version with the standard tooltips, together with its SmallEditorOld.exe.manifest file.

If the latter is in the same folder as SmallEditorOld.exe, ComCtl32.dll version 6.xx will be used (the exact version is displayed in the static control to the right of the toolbar); otherwise it will use version 5.82

- with 5.82, tooltips work fine.
- with 6.16 (my version on Win7-64), the tooltips seem to work, but check what happens if you move from below into one of the toolbar buttons: nothing happens. The bloody ttips start showing when you move horizontally and you cross empty areas. This is definitely "by design" and a "feature" generously given to us by our friends in Redmond 8)

And it seems this "feature" has been around 13 years ago, as a certain "Ivo" writes: "Can someone make sense of this madness??!"

The new version uses the more recent tooltips, and they appear to work fine. To build the editor source, SmallEditor.asc you need MasmBasic version 29 December. Have fun

[hutch--]

Yep, this one looks heaps better and the tooltips work fine.

[GuruSR]

Color scheme isn't my cup of tea and I can see how the top heavy menu and button bar would annoy those with wide screen monitors (means more scrolling).  I put my mouse over the folder icon to see what it was and the entire window vanished, then came back a few seconds later in the default position (which is off-screen), the Open shows &Open at the top, the Save is fine and both dialogues are tall.

My first suggestion, do away with the menu bar, it's a lot of wasted space just for 2 items, since you have that large tool band across, why not just use it, you went to all that trouble to have it and the menu really only offers language outside of the tool band.  Perhaps a gear icon for "Settings", you could put the Set Folder in there and a Language dropdown.

Oh, Setfolder dialogue is not parented, mis-clicked on the window instead of the dialogue and it went behind.

Not sure what other plans you have, but I've been (unsuccessfully) able to find any editor that would allow multiple windows open to the exact same document (being edited at the same time), and a lot of people would go "Huh?" at that, but a lot of times I'm writing assembler code and have to scroll all the way back up to add data or a const, the go back down and keep going, and there are times when I typo on a element name and it's because I can't see it without scrolling back up and down.  I've used those with splits, but that limits the editing area again and reading the flow of the code even harder, plus having multiple edit windows up to the same data on different monitors would be very useful for those in limited resolution environments (laptops, etc).

It does look good so far, but Avast didn't like it at first, sandboxed it, no idea why, but it did let it run normally afterwards.

GuruSR.

[jj2007]

Hi Guru,

Thanks for the detailed feedback :icon14:

Color scheme isn't my cup of tea

See line 1 of the source: b RgbCol(160, 255, 200)

and I can see how the top heavy menu and button bar would annoy those with wide screen monitors (means more scrolling).  I put my mouse over the folder icon to see what it was and the entire window vanished, then came back a few seconds later in the default position (which is off-screen)

Sounds bizarre - there should be just a tooltip. Anybody else seen such an effect?

the Open shows &Open at the top, the Save is fine and both dialogues are tall.

The & is a bug, thanks.

My first suggestion, do away with the menu bar, it's a lot of wasted space just for 2 items, since you have that large tool band across, why not just use it, you went to all that trouble to have it and the menu really only offers language outside of the tool band.  Perhaps a gear icon for "Settings", you could put the Set Folder in there and a Language dropdown.

The whole editor is a demo how to do multilingual toolbars and menus, therefore I'll rather keep the menu. As more functions are added, the toolbar will become too small anyway. In RichMasm btw, I have no toolbar, and menus are in the caption, and there is no statusbar - I like seeing many lines when I work on an assembler source.

Oh, Setfolder dialogue is not parented, mis-clicked on the window instead of the dialogue and it went behind.

Good point, thanks.

Not sure what other plans you have, but I've been (unsuccessfully) able to find any editor that would allow multiple windows open to the exact same document (being edited at the same time), and a lot of people would go "Huh?" at that, but a lot of times I'm writing assembler code and have to scroll all the way back up to add data or a const, the go back down and keep going, and there are times when I typo on a element name and it's because I can't see it without scrolling back up and down.  I've used those with splits, but that limits the editing area again and reading the flow of the code even harder, plus having multiple edit windows up to the same data on different monitors would be very useful for those in limited resolution environments (laptops, etc).

It does look good so far, but Avast didn't like it at first, sandboxed it, no idea why, but it did let it run normally afterwards.

GuruSR.

I know the problem very well See e.g. this post, second image, second point under "some notes":

- The yellow area "to build any"... on top is an optional extra window that serves to keep a portion of the document visible independently of the current edit position. Imagine you have a structure defined somewhere near the top, and you'd like to see the definition while working with it near the end of the document; just select the lines you want to see and press Ctrl F12 (if nothing is selected, the window disappears).

[HSE]

Hi JJ!

Work perfect here.

Just a minimum observation: C and W need a clear border for general purpose.

[GuruSR]

Hi Guru,

Thanks for the detailed feedback :icon14:

Sure, know when good feedback comes in, it helps immensely instead of "this thing doesn't work, fix it" types.

and I can see how the top heavy menu and button bar would annoy those with wide screen monitors (means more scrolling).  I put my mouse over the folder icon to see what it was and the entire window vanished, then came back a few seconds later in the default position (which is off-screen)

Sounds bizarre - there should be just a tooltip. Anybody else seen such an effect?

Found out what happened, turned out due to the window's location on startup (seems statically placed as do all the windows),  Avast sandboxed it, but because the window was so high and off-screen partially (I don't have a wide-screen, hate them for coding, I like the extra 15 lines of space), I didn't see the Avast sandbox frame above it.  It was fine afterwards, so sorry, thought I edited that part out.  Ooops.  Though, perhaps align the popup windows with their tool band icon, so it looks like the window came from there, rather than where they are now, the save/open seems to show up on the right side (around 800pixels across) and the Setfolder shows up at about 50pixels across.  And the non-parented Setfolder, let me open a Save and Open dialogue at the same time.

My first suggestion, do away with the menu bar, it's a lot of wasted space just for 2 items, since you have that large tool band across, why not just use it, you went to all that trouble to have it and the menu really only offers language outside of the tool band.  Perhaps a gear icon for "Settings", you could put the Set Folder in there and a Language dropdown.

The whole editor is a demo how to do multilingual toolbars and menus, therefore I'll rather keep the menu. As more functions are added, the toolbar will become too small anyway. In RichMasm btw, I have no toolbar, and menus are in the caption, and there is no statusbar - I like seeing many lines when I work on an assembler source.

I really must see if that pro 19" 4x3 monitor from Samsung is still available, sweet pixels that sucker is amazing to look at.  Still 1280x1024, but well, it's so nice on the eyes, you don't get fatigue from looking at it for hours on end.

Not sure what other plans you have, but I've been (unsuccessfully) able to find any editor that would allow multiple windows open to the exact same document (being edited at the same time), and a lot of people would go "Huh?" at that, but a lot of times I'm writing assembler code and have to scroll all the way back up to add data or a const, the go back down and keep going, and there are times when I typo on a element name and it's because I can't see it without scrolling back up and down.  I've used those with splits, but that limits the editing area again and reading the flow of the code even harder, plus having multiple edit windows up to the same data on different monitors would be very useful for those in limited resolution environments (laptops, etc).

It does look good so far, but Avast didn't like it at first, sandboxed it, no idea why, but it did let it run normally afterwards.

I know the problem very well See e.g. this post, second image, second point under "some notes":

- The yellow area "to build any"... on top is an optional extra window that serves to keep a portion of the document visible independently of the current edit position. Imagine you have a structure defined somewhere near the top, and you'd like to see the definition while working with it near the end of the document; just select the lines you want to see and press Ctrl F12 (if nothing is selected, the window disappears).

I'd love to see two or more windows open, for the same document with separate cursor positions for each, so I could click on one, add data, click on another, work on a proc, have another open to another proc that I can add code to to include the new data, would definitely save time on those long projects.  Any plans for an ini for options, <SARCASM>since we all love the Registry</SARCASM>...

GuruSR.

[jj2007]

I'd love to see two or more windows open, for the same document with separate cursor positions for each, so I could click on one, add data, click on another, work on a proc, have another open to another proc that I can add code to to include the new data, would definitely save time on those long projects.

I prefer a single screen-filling window, but jumping between different procs is of course an issue. I call my RichMasm solution "history":

The document's history is stored with the source, and by clicking on the left arrow, you can go to sections that you edited earlier. Hitting the Alt Left or Alt Right keys will do the same.

The MasmBasic source, for example, is now a bit over 30,000 lines, and hitting Alt Left/Alt Right is a convenient way to jump to the macros or procs that I edited recently. But the logic is not so simple, so that is not an option for the little demo here :icon_mrgreen:

Any plans for an ini for options, <SARCASM>since we all love the Registry</SARCASM>...

Nice idea :t Something like this?

include \masm32\MasmBasic\MasmBasic.inc      ; download
  Init
  Ini$("\Masm32\MasmBasic\Res\RichMasm.ini")
  PrintLine Ini$("prtL")
  PrintLine Ini$("prtR")
  PrintLine Ini$("prtT")
  PrintLine Ini$("prtB")
  PrintLine Ini$("FaceSrc")
  PrintLine Ini$("FaceFix")
  PrintLine Ini$("FaceProp")
  PrintLine Ini$("FaceLarge")
EndOfCode

Output:

Code Select Expand

700
900
100
700
System
Lucida Sans Typewriter
Tahoma
Arial

Excerpt from the ini file:

Code Select Expand

[App_Info]
prtL=700 ; 100*print margin left
prtR=900
prtT=100
prtB=700
...
FaceSrc=System
FaceFix=Lucida Sans Typewriter
FaceProp=Tahoma
FaceLarge=Arial


[GuruSR]

I prefer a single screen-filling window, but jumping between different procs is of course an issue. I call my RichMasm solution "history":

The document's history is stored with the source, and by clicking on the left arrow, you can go to sections that you edited earlier. Hitting the Alt Left or Alt Right keys will do the same.

The MasmBasic source, for example, is now a bit over 30,000 lines, and hitting Alt Left/Alt Right is a convenient way to jump to the macros or procs that I edited recently. But the logic is not so simple, so that is not an option for the little demo here :icon_mrgreen:

I actually always use a full screen filling window, just wish I could have more than one open, quick keys to jump between procs is handy, though not sure how much I'd use it, learning extra specific keys per editor can be a chore if you can't configure them to match and I know how much a pain that is to do when configuring them (unless the person knows the key code and manually adds them to the ini).

Nice idea :t Something like this?

Yes, the nice thing about using an ini file, is it's portability, throwing everything in it to save all the settings and even history would be a benefit to it and avoiding the registry even more, you could do testing on various systems and copy the ini over to quick setup each system or store both on a USB stick.

GuruSR.