I guess I'll weigh in here.

On the subject of Stardock's interests in OE. I'm the author of OE, I am not an employee of Stardock, so there is no 'investment' per se, I get royalties yes, but if you think about where OE fits into the scheme of Object Desktop, you can be assured that that amount of money doesn't justify much time into Object Edit . What little love it gets is more because I want it done than anything else. That said, I'll address some of these items, and we'll discuss them below. how's that sound ?

Regarding some of the items:

* Tabs

I'm the one that has resisted this from day one. OE is intended to be lightweight and the addition of tabs, and all of the MDI cruft that goes with it was something I wanted to avoid.

* Maximized State

This can be addressed fairly easily, it's just an over looked bug.

* LineCount Color

This should probably be user selectable.

* Having to go through Syntax->Syntax Style in the menu to get to the syntax selection is very awkward.

There existed a way to deal with this, but it was removed due to UI concerns. (a right click on the status bar indicator of the style got the style menu)

* Ability to add toolbar buttons for your syntax styles would be nice as you use some more often than other.

I personally would prefer to add a toolbar button for 'styles' that is a popup of the styles you can select from

* Be able to have one syn files apply to more than one file extension. As it's now, one for HTML and one for HTM, awkward.

Awkward, yes, faster, yes. The reason it's done this way is to prevent having to load each Syn at load to dtermine the file. As it stands now, it does so using a quick 'does the file exist name style.syn', which is significantly faster than iterating all the syn's to determine if the style is supported by any of them, in addition to preventing collisions of duplicate styles.

* Be able to define escape characters. For instance PHP sometimes becomes oddly highlighted if escape characters are used

This is partially implemented in a build to be released.

* When you scroll up or down a document and your cursor happend to move outside the area of the scrollbar it will scrollback to it's original position

This is a 'feature'. The original code moved the edit point to the currently scrolled viewpoint, but this was determined to be an incorrect behaviour as you had not changed your edit location. I'm still not positive what the 'correct' behaviour is in this case. I'm open to input. When you scroll, what should the 'edit' point be if you haven't clicked to change it?

* When searching a document, begin to search from the beginning when you've hit the bottom

Already done for a future build.

* Be able to indent block selection of text with tab

Doable.

* Option to add/remove the shell context menuitem.

I assume you mean from the preferences menu? It's possible, but there is a rub. The call to do so requires administrative priveleges, so this *will* cause major hassles on Vista.

* Plugins

They add a 'tools' menu which allows you to run the JavaScript using the Windows Script Host. If it isn't showing up, make sure the OEPlugins.dll is regsvr32'ed.

* Compare / Diff tool

That's really an external tool. it's possible to include, but now OE is stepping well beyond the 'simple fast little text editor'.

* autoscroll on the middleclick

Implementing this in the application creates conflicts with the various mousedrivers. It was there and was removed because if broke Logitech's mouse drivers. I think this is best left inthe domain of the mouse drivers and leave default scroll functions in place.

* Growing toolbar Bug

This is a bad interaction with some version of WB and the custom drawn control. It should be fixed in the latest revision of WB, as well as in the next revision of OE.

* Highlight a word and right click for an option to look up the definition in online dictionary of choice.

Cool, Effective, doable. Implementation details, should it support a single preference, or should it be defined via the syn style ?

* UTF-8 support. Currently OE can only handle ASCII and UTF-16 unicode.

This is a side effect of using the built-in Windows support for Unicode. It's UTF-8 support is a little incomplete.

* Correct the Right-to-Left language support (UTF-16). Currently, editing RTL Unicode text in a mixed language file leads to corruption

I think this is the same as the above issue, but I could use a bit more detail to address it.

* if word wrap is enabled line numbers get off

KNown issue, mostly fixed for the next release, but there appear to still be instances where the issue can crop up.

w00t! Thanks for the update.
It also must be a bug in the install script that OEPlugins isnt registered. I dont have that menu either.
And with the scrollbar thing, that 'feature' should be removed since it is very annoying.

Wow. I had this thread on my watch list but I haven't been notified about any activity.

I'd really like to see UTF-8 support. I sent an support ticked to stardock last week actually about this.

* When you scroll up or down a document and your cursor happend to move outside the area of the scrollbar it will scrollback to it's original position This is a 'feature'. The original code moved the edit point to the currently scrolled viewpoint, but this was determined to be an incorrect behaviour as you had not changed your edit location. I'm still not positive what the 'correct' behaviour is in this case. I'm open to input. When you scroll, what should the 'edit' point be if you haven't clicked to change it?

I think that as long as the mouse button is held down the scrolling should not revert to either the cursor point or the last view port even though it leaves the client area.
And I'd also prefer that if the mouse button is released outside the client area the scroll should stop where it is and not revert back to any previous positions then either.
My point view is that I often use the scrollbar very quickly, I slam the cursor in the general direction I want to scroll the content, so the cursor doesn't always remain within the client area of the scrollbar.

Yay! ObjectEdit's gettin some lovin!  I love using this program... I wish there was a little more complete documetation on writing the .syn files as well, if we're in the market for suggestions.

When I first subscribed to Object Desktop, I loved OE. As I used it more and more, I found more and more limitations, (many of which have been mentioned by thomassen earlier) and ended up switching to Notepad++. I have it on my USB key, my U3 drive (similar to USB key), my desktop and my laptop. Basically, I like it a lot. Not to knock your program, Dru, but take a look at Notepad ++ and see what can be done better, and what features you might like to add into OE. Looking at your post, you seem to have a good handle on that already.

I know I do need to take a new look at OE, and maybe I'll be switching back. Going to install now...

I'm still working on the changes. The rework to add tabs correctly broke alot of functionality and I'm really not happy with the overall functionality of the tabs. So, at this point, I've split the changes into two parts. Tabs are secondary (this is a codebase that was never intended to be MDI so tabs is really non-trivial) I hope to have something in the short term (end of May) that doesn't include tabs but does sport some of the changes, and then the Tabs version in June or July.

Andy

Sounds great.
The tabs are a mere convenience than necessary IMO.
UTF-8 support is one of my biggest hopes.

Fingers crossed for July

What do you mean? Localization of the program?
Or syntax highlighting of multiple languages in one doc? That can already be done you know.

BUMP. (so much for June or July)