Author Topic: SF_BINARY  (Read 354 times)

HSE

  • Member
  • ***
  • Posts: 477
  • <AMD>< 7-32>
Re: SF_BINARY
« Reply #15 on: April 21, 2017, 11:45:58 PM »
Oops! Work perfect today  8)

C:\Program Files etc

EDIT: Sorry not perfect.

Before (correct) RichMasm open the math file (the last open before close )

Now (wrong) RichMasm open other file, and later I open the math file. In this case the path say ...\OFFICE11\..

Apparently if last file is .rmm work well, if other then work wrong.

jj2007

  • Member
  • *****
  • Posts: 7070
  • Assembler is fun ;-)
    • MasmBasic
Re: SF_BINARY
« Reply #16 on: April 22, 2017, 01:22:29 AM »
EDIT: Sorry not perfect.

It's by design :icon_mrgreen:

RM uses Office11 for normal text and rtf files, because it's the fastest version. But when you try to open a *.rmm (RichMasmMath) file, and RM finds the two marker bytes for SF_BINARY, it switches to Office12 - because that's the only version that works reliably.

HSE

  • Member
  • ***
  • Posts: 477
  • <AMD>< 7-32>
Re: SF_BINARY
« Reply #17 on: April 22, 2017, 02:03:57 AM »
Oh! Sorry, I don't know where is ny crystal ball  :biggrin:

jj2007

  • Member
  • *****
  • Posts: 7070
  • Assembler is fun ;-)
    • MasmBasic
Re: SF_BINARY
« Reply #18 on: April 22, 2017, 02:28:44 AM »
It's very messy indeed. But that mix, Office11 for normal, Office12 for math files, works surprisingly well in RichMasm. I have used the Office11 version for several years now, it's rock solid. And fast - my frequently used sources are 20,000 and 30,000 lines, and they load in 0.5/0.7 seconds; saving is even faster.

jj2007

  • Member
  • *****
  • Posts: 7070
  • Assembler is fun ;-)
    • MasmBasic
Re: SF_BINARY
« Reply #19 on: April 22, 2017, 08:19:34 AM »
New version uploaded. I had a strange experience, one of the templates misbehaved and showed a lot of Chinese characters instead of source codes. So a wasted a couple of hours chasing a non-existent bug. It turned out that there was a RichEd20.dll in the doc's folder, from the last round of testing. And since all those DLLs are not compatible with each other, it showed garbage. Really, a big big mess, Microsoft :icon_redface:

But I learned something important: When loading RichEd20.dll, its companion msptls.dll wants to be loaded, too; and it needs the full path name, including the extension, otherwise you get some default DLL that is most likely incompatible with the main one.

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 4513
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: SF_BINARY
« Reply #20 on: April 22, 2017, 12:11:16 PM »
I guess it depends on how much "rich" you want. I am happy enough to use drag and drop, multi-level undo, margin width adjustments and all of the rest but I don't aspire to write a word processor as I aim specifically at a pure plain text ASCII editor without technicolor. I think what you have explained is yet another version of "Welcome to DLL hell".
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin: