Community

I actually like the new version of this, since I find it useful to have files maximized in textpad but still be able to see search/tools results at all times. An option though would be nice to choose between the two setups.

Any way another option could be created to not erase previous tool output?

Add one more vote to the way it used to always work. When first trying 5.x I said there has to be a way to put the search window back to the way it was so that's why I started checking the forum. Lo and behold, I wasn't the only one.

Then I read in the release notes that it was dockable and moved it and sure enough it became a separate window, but then I couldn't figure out how to dock it again! By fluke, I happened to double click on the caption and it got docked. Yup, give me the 4.x days back.

I also prefer the new behavior - especially for the Tool Output window.
(I've written a number of 'tools' which work best with the new docking
behavior.)

But I can see the benefit of an option allowing you to choose between
the new and old modes.

I've tried for several days to get used to using the Search Results window at nearly full size (which I need) and the auto-hide feature, so that I can go back and forth to editing without losing result. It's just not good enough, and I haven't seen any 5.x features that give me enough reason to sacrifice the old Search Results file.

I'm going to have to go back to 4.x.

While I have been deeply committed to textpad since its 16-bit days, some decisions in feature growth seem to indicate that internal power struggles manage to overshadow the loyal and devoted customer bases' wishes. This is turn tempers the glow we can muster when speaking of our favorite tools.

There never should have been an either/or choice forced upon the user regarding the handling of the "evaluation windows" (created & populated by the app's processing). Allowing the user to configure the behavior as needed is a basic rule of thumb when seeking both forward- and backward- capabilities.

As a long-time software professional, if I proposed such as a textpad dev team member and was shouted down--and of course analogies in my career are plentiful--my respect for the project leader immediately became bound to the end-result. While he may need time to sooth egos and endure lectures on its difficulty, if he's worth his salt the right thing will get done or, at the very worst, his lack of political capital becomes embarrassing threadbare.

Arguments to throw out working code rather than simply letting it be disabled may have to be endured during the SDLC, but they should not survive it. If the team doesn't want to do it, they're whining and a hiring a three-week hit man should straighten them out.

Not sure why I'm bothering but just in case someone at Helios does give a fiddle[swear word changed by poster before you remove the post], here is a BIG FAT LIE:-

Important:The installation process will preserve your current TextPad settings.

I knew upgrading was going to hack[swear word changed] me right off.

My Doc Selector & Clip Library settings ABSOLUTELY WERE NOT PRESERVED. Neither was the size of my window.

And in the process of trying to put them back how they were, I've managed to Tile all windows. I tried crashing TP using Task Manager to stop it saving the layout in my workspace, but Oh no, too late. I hate you.

Have you even heard of User Acceptance Testing?

For what it's worth, give me back the 4.7 way, which agrees with the majority of posts, however OF COURSE YOU STUPID [swear word deleted] ANALYSTS YOU DON'T REVOKE EXISTING FUNCTIONALITY PEOPLE HAVE COME TO DEPEND ON.

By all means, offer a different alternative.

What happened to the common sense approach we've come to expect of TextPad?

Oh and of course now I can't change the size of my Tool Output bar (neé Command Results window) without either reducing the amount of space available to my other documents, or having it hide what's behind it.

I'd much rather you focused on fixing existing problems (see prev post by me) than introducing new ones.

WHAT WE LIKE ABOUT TEXTPAD IS THAT IT'S RELIABLE.

Right, I'm off out to get astonishingly drunk, and if it's not fixed when I get back to my PC tomorrow, you're not getting any pocket money son. Let that be a lesson to you.

Primarily:

Anything that is only via MOUSE is a definite *NO*!

When I am coding, I am in kb speed daemon mode and I cannot emphasize this enough: I will never, ever, want something to force me to grab my mouse.

Except of course if the code I am building for the end-users needs mouse input after whatever compiler tool I am running may actually work and isn't spewing warnings :P

- - -

All besides which, secondly: (and even more importantly?)

I just plain liked the old approach. I set up my regex stuff to arrow up and hit enter and viola - I was on the right error line in my source as indicated by the compiler. It was beautiful. Why change?! Why not still offer the old way?!

Dear all,

I raised a bug report, not specifically to get the old way re-instated (that would be an enhancement request, and there already is one of those), but because the Tool Output window maintains focus after double-clicking, which is clearly wrong.

The nice people at Helios have provided me with a link to version 5.1 which isn't generally available yet - so I'm not going to include the link here, but expect them to announce it soon - which (I'm told - I haven't downloaded it yet) provides an option to use the old style way.

The uprising has begun!

Cloink.

Well, props to Helios for responding to their customers. TextPad really is awesome, and if they keep up the good attitude, it will get even more awesome!

:)

Please go back to the good 4.xxx behavior!!!

The new approach wastes my screen real estate by forcing splitting, a behavior that I hate (and which is one reason why I like programming with a lean mean text editor instead of a bloated IDE).

Kevin - I take it you didn't read my previous post, 2 up from yours.