Reply To: Multi-Edit v9.10 has been released??

Product Compare Forums Multi-Edit Support Multi-Edit v9.10 has been released?? Reply To: Multi-Edit v9.10 has been released??


Let me take your points in order. First, we value the entire package at the listed price, and don’t consider individual parts of it as worth any particular amount. Multi-Edit 9.10 contains considerably more than just those two items, and considerably more than the previous version, quite apart from those two Add-ons. It’s often the case with a new release of any product that quite a lot of the work that went into it doesn’t necessarily show in the user interface, or isn’t immediately obvious because it isn’t a portion of the functionality that any particular user might have been using, or even be aware of. Carl was merely pointing out two fairly major new features, not attempting to claim that they justify the entire price of the program.

Some people have objected to paying for a “minor update.” As Carl has noted, 9.10 is not a minor update, but a major upgrade. There’s some confusion surrounding this because of changes we made to our version number scheme that have only internal significance. I don’t think anyone would have raised the issue had we simply numbered this release as version 10.00. We almost did, but there had been much forum discussion concerning what would be in “v10,” and as most users had gotten a distinct impression of that feature set and had come to associate it with “v10,” we felt it would confuse and annoy people to call this release by that number, as it is not the release we referred to as “v10” in the earlier threads.

I’m not sure where in the help file you’ve run across a registration message concerning Trita, as no version I have has such a thing, even the most recent version in the code repository. What’s most likely is that you tried to run Trita as a standalone program; currently, our integration only allows it to be invoked from Multi-Edit’s Tools | Format Code menu item. Trita doesn’t handle registration keys in quite the manner you might think it does, and outside of our integration, it simply thinks it hasn’t been registered, and so, displays an error. We plan to improve the integration to allow standalone formatting; that improvement simply has lower priority right now than finishing up the full announced feature list for 9.10.

As for Evolve, whether you regard it as a major item will depend strictly on whether or not you have a use for it. While dBase and FoxPro may not be cutting-edge, they’re still in widespread use, and Evolve is anything but “obsolete code.”

As for the problems, well, some have indeed been around longer than anyone likes. We’re definitely aware of the problems, and are working on them. In a few instances we have a solution in hand, but held off on applying it for a bit, so as not to introduce too many changes into the codebase at once, at a time when we’d not be able to regression-test them as they should be. Many of the infamous “bad releases” of very obvious software (no names here, of course, for legal reasons, but every programmer knows of at least some of them) were so abysmal precisely because “improvements” were dropped in just before release, with no chance for adequate testing. We’d rather have a known intermittent problem present for a bit longer than risk foisting a disaster on our users (and here I personally speak as someone who has had two hard drives completely scrubbed by two such programs in the past).

Some other problems are taking longer to fix simply because they involve fairly major changes to the code. Anyone who has worked with a large, complex codebase running to hundreds of thousands of lines knows from experience that on occasion, problems that seem as though they’d be simple of solution can actually require modification to large swathes of code.

To go from general comments to the specific instances you mention, Michal has already pointed out the difference between tagging in C and C++ and TipWin. While it’s true that the bug you report exists in the tagging functionality, and was not explicitly listed in the v9.10 feature list, I was working on fixing it even before your post (I enjoy working on parsers, and tackled it as a “fun” project). Being very much a C++ hackie myself, I, too want the tagging to work as it should.

I’m not familiar with the problem you mention regarding Single Window Mode, as very few people use that mode any more, and it never reached me as a support issue. If you could contact Support[/url:2mnbpm0j”> with a description of the problem, preferably with a description of your setup and environment, and a sequence of actions that will replicate the problem, it will reach me, and I’ll get to work on it.

The “new 9.10 behavior” you report sounds very much like an issue we’re dealing with. If it is, in fact, what your description makes it sound like, it’s an issue with earlier versions of Multi-Edit, as well as a number of other programs, and is tied to a faulty hotfix for Windows XP, numbered KB811493 or, in the older Microsoft format, Q811493. Do a search through our Forum, our TWiki Forum, and the older archived BBS for those numbers, and you’ll find my earlier posts on the topic, with explicit instructions on how to fix the bad hotfix. This problem is triggered, and sometimes exacerbated by a known bug in our code, which we will fix as soon as feasible (this one falls into the “change a lot of code” category). Actually, it’s a matter of semantics whether one considers this one a bug or not, as it only became an issue under Windows XP, because of changes Microsoft made in its message-queue handling. They were probably done to increase the apparent responsiveness of XP, but had the unfortunate side-effect of breaking a number of programs under intermittent circumstances. You can somewhat mitigate the problem in the short run by switching from Multi-Edit’s native File Open dialog to the “Explorer” dialog, which has less internal latency.

We hope you won’t give up on us, as we’re not giving up on trying to make it work for you.