A guide to the RichMasm editor

[FORTRANS]

Hi,

   Just for feedback, a screenshot.

HTH,

Steve

[jj2007]

Hi Steve,

The lines are wrapped. What's your screen resolution? Mine is 1366x768, and even with enlarged fonts they are not long enough to wrap. Or did you mean something else?

Jochen

[FORTRANS]

Hi Jochen,

The lines are wrapped. What's your screen resolution?

   Usually 1024x768.  Sometimes higher, though not very often.

Mine is 1366x768, and even with enlarged fonts they are not long enough to wrap. Or did you mean something else?

   Well, yes the lines wrap, but I just thought you might find it
useful to see your work on another's system.  Maybe the colors
and fonts are different for instance.  You may try to have all your
computers set up similarly.  I used to do that a while back, and
had some odd results when one of my programs was used on
someone else's computer.  (Code page different I think.)

Regards,

Steve N.

[jj2007]

Well, yes the lines wrap, but I just thought you might find it useful to see your work on another's system.  Maybe the colors and fonts are different for instance.

Colours and fonts look similar, but 1024x768 is indeed a bit low for today's standards. Anyway, it's the browser who decides when to wrap lines.

But I understand the problem very well. Often, pages just look garbled, OK buttons are below the visible area, etc - messy sites made by professional web developers who only made one small mistake: to assume that the user also has that great 4k screen that a decent IT professional is entitled to enjoy 8)

[HSE]

Good practice is:

Code: [Select]

include \masm32\MasmBasic\MasmBasic.inc         ; download
  if 0  ; copy the line below, then hit F6 to get the db version
        chartab                 dw "10","01","12","21","13","31"
        ; expected output:
        chartab                 db "0","1","1","0","2","1","1","2","3","1","1","3"
  endif
  Init                          ; *** translate Masm dw format to db for use with UAsm ***
  Let esi=Clip$()               ; get string from clipboard (limit is about 160k)
  lea ecx, [2*Len(esi)]         ; the byte format is longer, so we need a bigger buffer
  Let edi=New$(ecx)
  push esi
  push edi
  .Repeat
        lodsb
        If_ al=="w" Then mov al, "b"    ; dw->db
        stosb
        .Break .if !al
        .if al==34
                push [esi]
                lodsb
                movsb           ; first digit
                mov al, 34
                stosb
                mov al, ","
                stosb
                mov al, 34
                stosb
                pop eax
                stosb           ; second digit
                movsb           ; second quote
        .endif
  .Until 0
  pop edi
  pop esi
  Inkey "Before: ", esi, CrLf$, "After:  ", edi, CrLf$, "Copy to clipboard? (y)", CrLf$
  If_ eax=="y" Then SetClip$ edi
EndOfCode And everybody can to choose colors

[jj2007]

Good practice is:

So why do almost all IDEs and many programming sites come along with syntax highlighting? Bad practice?

[HSE]

In the box is more easy to copy!!

LATER: I also have configurated 1024x768

[FORTRANS]

Hi,

   BTW, if I have a choice of wrapped comments or uncommented
code, I choose having wrapped comments.  Many denizens of
this forum seem to like uncommented code though.  Maybe they
have a phobia of wrapping.  <g>

Cheers,

Steve

[jj2007]

In the box is more easy to copy!!

That was before the Mozilla "coders" decided to disable the Code: [Select] function :(

I have a choice of wrapped comments or uncommented code, I choose having wrapped comments.

The code box doesn't wrap them, that may look better but to read them you have to click the horizontal scroll bar. Not the best solution either :icon13:

  Recall Utf8$(wCL$()), L$()    ; translate the file supplied through the (Unicode) commandline to a text array (if the file is Unicode, the strings will be in UTF-8 format; if needed, you can get Unicode back with wRec$(L$(n)) - see also ConvertCp$)

Code: [Select]

  Recall Utf8$(wCL$()), L$() ; translate the file supplied through the (Unicode) commandline to a text array (if the file is Unicode, the strings will be in UTF-8 format; if needed, you can get Unicode back with wRec$(L$(n)) - see also ConvertCp$)


[jj2007]

I am trying to figure out if it's worthwhile to look for the debugger paths when doing a fresh install of MasmBasic. Currently, the default paths are hardcoded (see: integrated debugging) to

\Masm32\x64Dbg\release\x64\x64dbg.exe for 64-bit debugging
\Masm32\OllyDbg\ollydbg.exe for 32-bit code.

Therefore the question: Where are your debuggers located?

[Biterider]

Hi
only as a hint, Visual Studio stores the debugger location here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]


Biterider

[LiaoMi]

I am trying to figure out if it's worthwhile to look for the debugger paths when doing a fresh install of MasmBasic. Currently, the default paths are hardcoded (see: integrated debugging) to

\Masm32\x64Dbg\release\x64\x64dbg.exe for 64-bit debugging
\Masm32\OllyDbg\ollydbg.exe for 32-bit code.

Therefore the question: Where are your debuggers located?

Unchangeable folder paths in this case better  :P

[jj2007]

Code: [Select]

include \masm32\MasmBasic\MasmBasic.inc
  Init
  PrintLine GetRegVal("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug", "Debugger")
  SetReg64
  Inkey GetRegVal("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug", "Debugger")
EndOfCode
yields
"C:\Masm32\OllyDbg\ollydbg.exe" -AEDEBUG %ld %ld
"C:\Masm32\x64Dbg\release\x64\x64dbg.exe" -a %ld -e %ld

I attach the project. These are the just-in-time debuggers, should be fine :t

Btw a pretty old key: The AeDebug subkey stores user preferences for Dr. Watson and other debugging tools that run on Windows 2000

No such key on Win10, but Olly shows up at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RADAR\HeapLeakDetection\DiagnosedApplications\ollydbg.exe 

Unchangeable folder paths in this case better  :P

Why that?

[LiaoMi]

Unchangeable folder paths in this case better  :P

Why that?

Hi,

the debugger often receives updates, sometimes there are errors that you need to debug. I have three versions, clean current release, stable version for work, and the current version with plug-ins, this package is always updated by adding plugins or changing the settings. Therefore, the exact binding for me is better 

[jj2007]

I have three versions, clean current release, stable version for work, and the current version with plug-ins, this package is always updated by adding plugins or changing the settings. Therefore, the exact binding for me is better 

OK, so the best solution will be to
- test if a debugger is already set in RichMasm's prefs
- if not, check for the registry key
- if there is none, see if there is *dbg*.exe inside the \Masm32 tree.

I guess that will add a few hundred bytes to RichMasm's 72kB :(