OP
goodintentions
Active Member
Well, I'm in panic mode, too, because I just discovered a bug in my new update. Don't know how I missed it in my tests yesterday.
Well, I'm in panic mode, too, because I just discovered a bug in my new update. Don't know how I missed it in my tests yesterday.
Well, I don't know if your bug is the same as what I'm seeing...but when I open a plain text document, all carriage return/line feeds are ignored...it's one big block of text. I opened the file in another plain text editor and it definitely said the file had Windows line endings (I've worked on Linux a lot over the years, so non-Windows line endings are always a possibility).
I'm certainly not in panic mode over this. It's why I like plain text...there are lots of tools available!
Haha, it's my first try at translating html, doc, docx, and rtf to txt.
The bug I'm referring to is opening doc and docx file. It's just giving a blank page even though the file is not empty.
Saving to the various formats work wonderfully. Saving to pdf works wonderfully. Opening rtf and html works wonderfully. It's just opening doc and docx that's not getting results.
I'm sure it's something like a regression or some other stupid bug.
Regarding MS support, here's something else to think about. I just realized MS hired a bunch of robots for their support team. Why do I say that?
They just put up a sticky telling everybody they are aware of the issue with the support site and that people should use the forum for other problems.
Well, people are reporting some problems on the forum, and their responses are still "please submit a support ticket..." and then the support link, which is still throwing an error.
I find it amusing that a multi-billion dollar company can't even hire human support personnel and instead use robots.
No library and no api call. I wish it was that simple...Well, Google has self-driving cars, I'm sure that makes MSFT want to try out robotic support personnel.
As far as text conversions go, I'm more than willing to be a guinea pig.
And a question - purely out of curiousity, because I haven't written code for close to 20 years but I remain interested - how does one go about opening and saving docx files? Is there a library or API call? Surely you don't have to figure out your own conversion routines, which would seem to be a ridiculous thing to do. But I really have no clue...last time I had to deal with anything like that, I was coding VBA inside of Word 97, so it wasn't an issue.
Thought you'd like to know that I just added in a subroutine to render the plain text correctly. It's not a blob of text anymore LOL. Will send out update right now actually.Well, I don't know if your bug is the same as what I'm seeing...but when I open a plain text document, all carriage return/line feeds are ignored...it's one big block of text. I opened the file in another plain text editor and it definitely said the file had Windows line endings (I've worked on Linux a lot over the years, so non-Windows line endings are always a possibility).
I'm certainly not in panic mode over this. It's why I like plain text...there are lots of tools available!
Thought you'd like to know that I just added in a subroutine to render the plain text correctly. It's not a blob of text anymore LOL. Will send out update right now actually.
It's not really a problem or difficulty. In fact, it shouldn't even be an issue as most computers these days have way more memory than they need most of the time. The problem was purely artificial due to my own experiment. One of the goals I've set for myself is trying to be a minimalist with this app. So, I thought let's be a stingy with the memory. Ehhh, didn't really work out the way I imagined. Next update will remove all limitations.OK, so I am not a programmer, though I once played one on television (not really). But I've gathered a little knowledge here and there, and since a little knowledge is a dangerous thing, I will ask a question that will out me in danger of being laughed at:
Why is document size limited to available memory?
I know working with documents larger than available memory is possible; Wordstar did it back in the 1970s, creating one or two swap files on disk, one for the portion of the document "above" what was currently in memory, one for the portion of the document "below." Naturally this meant there were disk access delays when pulling data from disk into memory, but it allowed Wordstar and similar programs to work with documents much larger than the miniscule amount of free RAM present on most CP/M machines.
Is this something that has gone out of style, simply because most machines have loads of RAM and most documents aren't all that big, or is there something else that makes swapping like this difficult?
. . . .
On another note, I'm going to start learning how to work with 3-D animation. I want to build games. Anyone here have any pointer on how I should start?