10.1C OEA First Impressions

And if OEA can't remember where I was, could someone post shortcuts for the template / macro section? Having to navigate to the template section every time I want to change something is extremely annoying.

I have a number of macros / templates which are only a little different. Instead of making me cut 'n' paste them (and having to navigate back to the templates window every time I test a macro), it would be nice to be able to copy one template to another and then edit the copy of the template.

Editor templates "restore defaults" doesn't ask if you really want to do that - which means all the changes I'd just made've gotten wiped out.

In fact, this button should only restore the originally named templates, not wipe out the user defined templates unless confirmed to do so.

"window->preferences" remembers where I was last?

I'm wondering how you're getting to the ABL editor preferences. From the sound of it, you're right-clicking on the editor pane and select Preferences from the menu. That will take you to the "General - Editors - Text Editors" preference. Hence the need for hitting the "cryptic clear button". (now that you mention it, I also wonder why it doesn't take you directly to "OpenEdge Architect - Editor")

How about this for an alternative. Use the menu to select "Window - Preferences". The same dialog will open, but now with all Eclipse preferences visible (no need to hit the cryptic clear button). You will also find that the selected location is the last place that you were - regardless of whether you hit the "OK" or "Cancel" button last time.

If you edit a macro and rename it, you'll be prompted whether to actually rename it or if you want to create a copy with the new name.

Another alternative would be to export one of your macros and then edit the .xml file, copying the sections as often as you want, updating the descriptions and patterns. Import the .xml file and you have all your macros available.

If you want your macros to be available on multiple machines, the Export and Import functions are your friend.

I'm wondering how you're getting to the ABL editor

preferences. From the sound of it, you're

right-clicking on the editor pane and select

Preferences from the menu.

Correct.

That will take you to the

"General - Editors - Text Editors" preference.

which I can understand - the first time. Successive times it should remember where I was and put me back there.

Hence

the need for hitting the "cryptic clear button".

(now that you mention it, I also wonder why it

doesn't take you directly to "OpenEdge Architect -

Editor")

good question. My bigger gripe is that it doesn't remember what I'd opened and where I'd been the last time, but instead resets itself to it's initial minimal configuration.

How about this for an alternative. Use the menu to

select "Window - Preferences". The same dialog will

open, but now with all Eclipse preferences visible

(no need to hit the cryptic clear button). You will

also find that the selected location is the last

place that you were - regardless of whether you hit

the "OK" or "Cancel" button last time.

Which is good - now that I know it's there. But for someone new to the product who right-clicks and goes to the preferences, the current behavior is extremely annoying and time consuming.

Tim, I suggest that you export the macros, edit and add to them in your favorite editor, and then delete everything and reload them. Much easier than trying to do it one at a time in situ.

Tim, I suggest that you export the macros, edit and

add to them in your favorite editor, and then delete

everything and reload them. Much easier than

trying to do it one at a time in situ.

After my experience last night, this certainly sounds like a better idea to me.

I might note that this has also been handy to me when re-installing and moving to new versions since I already have my keyword file ready to go.

Of course, something about this mechanism changed, I think, with 10.1C and I haven't looked at how it might be different now.

Well, I'm back, and this time I've spent some time with some Eclipse training videos, specifically the "Working with the Eclipse Workbench", which I found to be extremely instructive, and made a lot of sense out of what Eclipse can do, and how it does it.

The url is: http://eclipsetutorial.sourceforge.net/workbench.html

I've also figured out that projects can be pointed at existing source code directories, and that associations can be made between file extensions and editors, etc.

However - right now I seem to be stuck. A number of files I regularly use have "non-standard" extensions - like pp, sp, spi, tt, pds, and the like.

So when I asked the editor to make a new program file "file->new->abl procedure" will not permit any other extension other than ".p".

This isn't good, because while .p is a pretty standard name, it's not the only name one might find out there.

Another issue I'm running into is getting the color-coding to activate on the editor window. ".p" programs are color-coded fine, but other non-".p" files, while they appear to be properly parsed as ABL files, there's no color coding on them, and even with the new knowledge I have about finding things in Eclipse, I haven't been able to find a setting to turn color-coding on.

Now, I'll have to admit, this is not a "stock" ABL OEA installation, on recommendation from the PEG I downloaded the J2EE version from the Eclipse website, and imported the OEA plugins from the OEA plugin installation directory, so I don't know if that's causing a problem or not.

I'm thinking that once I get my head around this thing, and get it configured the way I like, this'll be one sweet environment to work in.

clear out a duplicate post

Hi Tim,

I suggest you log a bug for the file extension restriction since it is entirely artificial and should be based on the available file types, and not just a single extension. The exception is for class files (.cls extension) which can't be changed since the ABL requires it.

Second, the color coding is actually associated with the content type of a file, and not the editor. To get full support for alternate extensions you need to do three things.

1. Associate the new file extension you want with the ABl editor (There are three, so you can pick which icon you want). (General->editors->file extensions)

2. You need to associate the new file extension with the ABL content type. (General->Content Types->Text->ABL Source File)

3. If the file is considered compilable (e.g. not an include file), you need to add the file extension to the list of compilable file extensions. (OpenEdge->Editor->Build)

Certainly one of the first things I would do is to add your "special" extensions to the list of compilable extensions or one of the other slots as appropriate. You will want to do this anyway in order to access those files in OEA.

I suggest you log a bug for the file extension

restriction since it is entirely artificial and

should be based on the available file types, and not

just a single extension. The exception is for class

files (.cls extension) which can't be changed since

the ABL requires it.

Will do.

Second, the color coding is actually associated with

the content type of a file, and not the editor. To

get full support for alternate extensions you need to

do three things.

1. Associate the new file extension you want with

the ABl editor (There are three, so you can pick

which icon you want). (General->editors->file

extensions)

done.

2. You need to associate the new file extension with

the ABL content type. (General->Content

Types->Text->ABL Source File)

Ok this is really counterintuitive. The tree I'm seeing is Java Class file -> text, and then with I hit "+", there's the OpenEdge ABL Source File listing.

3. If the file is considered compilable (e.g. not an

include file), you need to add the file extension to

the list of compilable file extensions.

(OpenEdge->Editor->Build)

done.

And that seems to get color-coding for my non-".p" files.

It really shouldn't be this hard to do though.

Not sure where you are seeing this Java Class file thing. I was talking about Window -> Preferrences -> OpenEdge Architect -> Editor -> Build

Not sure where you are seeing this Java Class file

thing. I was talking about Window -> Preferrences ->

OpenEdge Architect -> Editor -> Build

In replying to Matthew Baker, I was chasing down the "content type" input field, and that's where I saw the java stuff. I've also found the screen you mentioned, and have it properly populated.

Moving along -

Having solved the issue with getting the color-coding working, I'm trying to get the key bindings to work the same way I'm used to in Ed4Win, specifically if I do a ctrldown or ctrlup, the screen'll move up or down with the cursor staying in the same relative place in the window.

There doesn't seem to be any key bindings in Eclipse which do the same thing - it's either move up or down a line, or scroll the entire window up or down, with the cursor remaining on the line it was on. This latter configuration's a problem because when the cursor's moved, the screen re-centers on the cursor and then it's moved.

I'm thinking I'd need to bind two actions to a single keystroke - move up/down, then recenter the window. However, I haven't seen anything in Eclipse which indicates this is possible.

Is there a way to get the functionality I'm after?

Back to the colors again - a bunch of "delimiter" type characters - such as:

=

.

,

(

)

+

-

are all colored black, which is a problem since I've selected a black background.

What make this even more interesting is that if I do this:

ASSIGN it.p.

the trailing "." looks the way it should. If I do this, however,

the trailing period is black, and hence invisible against a black background.

Entering something like f(x) - both of the function's parens are black, and hence invisible.

I haven't been able to find a setting to make these characters "reappear" as looking at the likely configuration suspects hasn't shown a way to specify a black color that would seem to apply to.

It's now Nov 13, and no comments / helpful hints on how to fix this issue from Progress?

Hi Tim. I've never before had the urge to modify OEA colours, but I've just tried out your black background scenario and I can see all the character as expected (regardless of layout).

I went to General -> Appearance -> Editors -> Text Editor and set the Background Colour to black. I also set the Current line highlighter to violet.

I then went to OpenEdge Architect -> Editor -> Colors (sic) and change Default to white.

I've attached a screenshot, so that you can see why I prefer the default colours

I'm glad someone's seeing all the chars they expect to see , but that doesn't solve my issue.

I've spent some time in the menu choices you've mentioned, and I think I found some color settings elsewhere, but I'm still stuck with these blacked-out characters, even though none of the colors I've chosen - except for the background - is black.

I've attached a screenshot of what I'm seeing - the "=", "+", and other characters are all look like they're MIA....

Did you do the default one that he mentioned. That sure sounds like it might be the key.

After a bit of trial & error, I believe those characters are controlled by General -> Editors -> Text Editors -> Foreground Color.

...and now my colours are unbearable !

My eyes go blind! Jamie, I hope for you that there's a reset to default button...

Ah-ha! The foreground was the system default, which I'm guessing is black. Un-checking that, and all my punctuation characters have appeared.

Yay!

Now on to the next problem....

Moving along -

Having solved the issue with getting the color-coding

working, I'm trying to get the key bindings to work

the same way I'm used to in Ed4Win, specifically if I

do a ctrldown or ctrlup, the screen'll move up or

down with the cursor staying in the same relative

place in the window.

There doesn't seem to be any key bindings in Eclipse

which do the same thing - it's either move up or down

a line, or scroll the entire window up or down, with

the cursor remaining on the line it was on. This

latter configuration's a problem because when the

cursor's moved, the screen re-centers on the cursor

and then it's moved.

I'm thinking I'd need to bind two actions to a single

keystroke - move up/down, then recenter the window.

However, I haven't seen anything in Eclipse which

indicates this is possible.

Is there a way to get the functionality I'm after?

So if I understand you correctly. If you are at say the third line from the top and that line is the hundredth line and you press this key 10 times, you will be on the 110th line and still the 3rd from the top of screen still?

That doesn't sound like something I have seen a lot and if it is something that you really really think is going to be useful (for not just yourself but all Eclipse users) I am sure there is a way to pass it onto the Eclipse Community (hey, you might even be able to implement it and give it to the community).

Lastly, if there isn't away to do it (have you asked in Eclipse forums) and it is a game break (especially if it is more important then the other functionality Architect gives you) perhaps you are better off staying with what you know as much as you can.

Molly

I was also worried for a minute there, but indeed there are Restore Defaults buttons on both of the colour selection pages

So if I understand you correctly. If you are at say the third line from the top and that line is the hundredth line and you press this key 10 times, you will be on the 110th line and still the 3rd from the top of screen still?

What you've described sound more like page-up/page-down.

What I have right now with ED4Win, if I hit ctrl-up or ctrl-down, the file shifts up or down, but the cursor's position relative to the window doesn't change. I've liked this functionality as it doesn't require much eye movement, compared to trying to follow the cursor through a file as happens with a straight up/down cursor movement.

That doesn't sound like something I have seen a lot and if it is something that you really really think is going to be useful (for not just yourself but all Eclipse users) I am sure there is a way to pass it onto the Eclipse Community (hey, you might even be able to implement it and give it to the community).

From what I've seen in Eclipse so far, it looks like it's got the kitchen sink already, so why not add a little faucet on the side?

Lastly, if there isn't away to do it (have you asked in Eclipse forums)

No, but I haven't found the appropriate Eclipse forum yet, and was hoping that Progress - since they're promoting this as the "next gen" IDE would have someone who'se used it in a PSC context and could answer the question.

After all, if a vendor wants to get it's user base to adopt something, they should do their best to support the user base directly and not shunt them to a different - and unfamiliar - support forum.

and it is a game break (especially if it is more important then the other functionality Architect gives you) perhaps you are better off staying with what you know as much as you can.

First of all, you're asking the user base to abandon their current tools in favor of OEA. To do that means they have to adopt what they've done for years to a completely different toolset, and they're going to want to "port over" how they've done things to that new tool as much as possible. So, my questions are just a public example of someone who'se doing their best to work through that process and come out the other end able to productively use this tool.

One consequence is that people are going to ask how to do certain things - like what I'm asking about here - with this new tool.

So let's not be hasty about telling me (and the other users who are reading this) to "like it or leave it" in response to questions like this.

Plainly put, not being able to see characters in a window is a deal-breaker. Not having a "scrolling cursor" (or whatever you want to call it) isn't. But if there's an easy way to accomplish that, then I'd much rather do that if I could.

From what I've seen in Eclipse so far, it looks like it's got the kitchen sink already, so why not add a little faucet on the side?

If you can convince the Eclipse community, you will probably get it, but not in the current release.

The closest I've seen is ctrl+up/down which scrolls the editor area but leaves you on the same line.

The closest I've seen is ctrl+up/down which scrolls

the editor area but leaves you on the same line.

and when you move the cursor, the file position snaps back to wherever the cursor was, as opposed to what's in the window now.

If that could be adapted, that'd be another item on my "nice to have" list checked off.

After all, if a vendor wants to get it's user base to

adopt something, they should do their best to support

the user base directly and not shunt them to a

different - and unfamiliar - support forum.

The latest OpenEdge release is all about opening the Progress environment to yet another technology (.NET). OpenEdge developers will do good, to get used to other forums. There are so much more ressources available on the web than PSDN can ever offer. The same is true for the Eclipse community.

No, but I haven't found the appropriate Eclipse forum

yet, and was hoping that Progress - since they're

promoting this as the "next gen" IDE would have

someone who'se used it in a PSC context and could

answer the question.

After all, if a vendor wants to get it's user base to

adopt something, they should do their best to support

the user base directly and not shunt them to a

different - and unfamiliar - support forum.

I actually have a different personal view about this (with emphases on the word Personal). I think part of the reason Progress did go for Eclipse rather then do it themselves was so that we didn't have to worry about every single editor feature and could get all the benefits of the enhancements to the underlying technology. So I hope we encourage people to use Eclipse based OpenEdge Architect because it is or is becoming the best IDE for developing ABL code. I hope with that Eclipse base that we encourage people to go out and find the best non-progress plugins for doing non-progress related work (i.e. HTML, Java, Javascript editing) and that we encourage users to get involved in the Eclipse community to better Eclipse for the betterment of all Eclipse users. I hope that development concentrate on fixing issues to do with OpenEdge specific problems and only fix Eclipse issues that are necessary to meet Progress goals.

First of all, you're asking the user base to abandon their current tools in favor of > OEA

Yeah, I would say only come over if there is a benefit and if there isn't don't just use it because we asked nicely (again a personal opinion).

I also think that when making these moves you have to understand that part of deciding which is better is seeing if moving to the new methodology that goes with the new tool works for you. If it doesn't, it will not make for a happy move.

I did a little research and it doesn't appear that there is a basic method of doing what you want. That's not saying that there is no way of doing it, but its going to take some research to find out how to it and possibly some low level programming.

I think this is sound. Why have PSC spend money writing a basic editor when could be spending it doing something specific to OpenEdge.

Going from environment A to environment B, there is always going to be something about environment A that one prefers ... or at least is used to ... but is not there in environment B. With Eclipse we have a context where a word in the right ears might actually add the feature, if it really seems useful and, if one doesn't mind Java, one could even add it oneself. ED4W has been a good tool over the years, especially given that there is just one guy soldiering away, but I think the lure of OEA well exceeds the few things that I like better in ED4W.

OpenEdge developers will do good, to get used to other forums. There are so much more ressources available on the web than PSDN can ever offer. The same is true for the Eclipse community.

I agree - however PSC needs to do a better job of pointing people to the right spots to post their questions as opposed to telling them to figure all that out themselves.

Also, there's plenty of Eclipse resources, which PSC would do well to post a directory to, and keep up-to-date over time. For instance, I found this webinar: http://eclipsetutorial.sourceforge.net/workbench.html to be absolutely invaluable in explaining how things work, and how to find things in Eclipse.

PSC needs to develop a directory of related links which people can go to to figure out how to use this new tool.

After all, if a vendor wants to get it's user base to adopt something, they should do their best to support the user base directly and not shunt them to a

different - and unfamiliar - support forum.

I actually have a different personal view about this (with emphases on the word Personal). I think part of the reason Progress did go for Eclipse rather then do it themselves was so that we didn't have to worry about every single editor feature and could get all the benefits of the enhancements to the underlying technology.

You misread what I wrote - I'm not advocating that PSC write the tool, but that having come out with this tool, they provide better user support for it - even if it's just to point people to appropriate places in the Eclipse forums where their question's already answered or can be posted.

So I hope we encourage people to use Eclipse based OpenEdge Architect because it is or is becoming the best IDE for developing ABL code.

And for that to happen PSC absolutely must provide better developer support for the tool, particularly the ABL-side of it.

I hope with that Eclipse base that we encourage people to go out and find the best non-progress plugins for doing non-progress related work (i.e. HTML, Java,

javascript editing)

Go out and find? Why not promote the tools / plugins you've found useful already, and give people an idea of where they can look? You're putting too much of the work for this on already-busy developers.

and that we encourage users to get involved in the Eclipse community to better Eclipse for the betterment of all Eclipse users.

It's a nice thought - if developers in shops out there permit their developers to do that.

I hope that development concentrate on fixing issues to do with OpenEdge specific problems and only fix Eclipse issues that are necessary to meet Progress

goals.

I don't want Development to do non-OE specific stuff either, but I would hope for better forum support for OEA from PSC.

First of all, you're asking the user base to abandon their current tools in favor of OEA

Yeah, I would say only come over if there is a benefit and if there isn't don't just use it because we asked nicely (again a personal opinion).

and how are users going to find out if there's benefit for it if the hoops they have to go through to get it working is greater than their determination to get the tool working?

I also think that when making these moves you have to understand that part of deciding which is better is seeing if moving to the new methodology that goes with the new tool works for you. If it doesn't, it will not make for a happy move.

Agreed - which is why PSC needs to do a better job of supporting the tool here on PSDN and help people get past the pain of initial adoption and get to the "meat" of the tool where it can really perform for them.

I did a little research and it doesn't appear that there is a basic method of doing what you want. That's not saying that there is no way of doing it, but its going to take some research to find out how to it and possibly some low level programming.

Which is fine - as I wrote earlier, it was a "nice to have", not a "got to have."

Maybe I am too close to it and see the work that is done to point people in the direction they need to go but it would seem the main place to do that is the Conferences we have during the year and I know that we had Architect Workshops at Exchange and PTW Asiapac at least and there were presentations in the last couple of years on using Architect and the power of eclipse. Those presentations are available on here.

The argument you are making about Progress having to be more supportive of users from an Architect stand point is the exact argument why I don't think we should be pointing people to particular plugins! If we say Plugin Blah is the best for HTML editing, there will be some that will want us to support it.

I do think there is more we can do and that sharing knowledge is extremely important but I do think that at some point you have to take it on your own back to go to google and search out information when you want it. I would also love to see the community feed back that information as we are all in the same boat and in most cases the community are using these tools a lot more then a lot of us get the chance too and they have the knowledge.

JMTC

PSC needs to develop a directory of related links

which people can go to to figure out how to use this

new tool.

I'm pretty sure, that google will always have more >relevant

Agreed - which is why PSC needs to do a better job of

supporting the tool here on PSDN and help people get

past the pain of initial adoption and get to the

"meat" of the tool where it can really perform for

them.

There have been many threads here on PSDN asking for us the users to share our experience and information about the plugins used. I believe that's also very valuable information here.

Right now, there is a series of WebEx sessions held by Sunil (lead architect or OE architect) on getting started with OEA:

- using projects and workspaces

- preferences

- ....

Maybe he won't be/haven't been talking about black background in the editor, but a lot of other getting started type of things.

Right now, there is a series of WebEx sessions held

by Sunil (lead architect or OE architect) on getting

started with OEA:

Here's the link to those: http://www.psdn.com/library/kbcategory.jspa?categoryID=2130

I'm pretty sure, that google will always have more

>relevant

Have you tried using Google to find a specific plug-in? I've done some poking around, and the Eclipse plugin ecosystem is rather tribble-like, which makes finding something specific a challenge.

I'll probably get yelled at for suggesting something other than PSDN, but, Tim, perhaps you could take the initiative to create a book page on OE Hive covering configuration and plugins for OEA. We could point to the materials on PSDN and then people could add child book pages for each plugin they had experience with ... how to install, dependencies, virtues and flaws, etc. Similarly, people could create child pages for various tasks ... you ought to be all set to write one on color management by now!

PSC has done a number of things to help, including the Exchange presentations, webinars, and various white papers. But, they aren't all in one place and they aren't always visible to the people who need them. Plus, they only cover what they cover. E.g., Sunil has done some good presentations on projects and workspaces, but one can only do so much in one part of one presentation. It would be nice if people could contribute comments, add notes, ask questions, maybe make a little presentation on the particular way they used these tools to solve a particular development issue.

I'm watching one of Sunil's "Working with Workspaces and Projects" presentation, and one surprise was that PSC creates 1 AVM session for each open project.

I'm curious about the rationale behind that - I had (ahem) assumed it was one AVM per workspace, not project.

In many cases one wants different database connections for each project (or no database connection for some projects). And, one may want other differences too, reflecting the differences in the project's purpose. Since we have no connection object in ABL, that necessitates one AVM per project.

The piece I hadn't realized before is that one can close projects one is not actively working with and thus shut down the corresponding AVM.

That kind of begs the question on how one should organize "projects". What level of abstraction should there be when mapping source directories, etc. to projects.

For instance, in situations where one has the following structure:

/root/shared

/root/module1

/root/module2

/root/module3

Should all that go into one project, rather than 4?

What division of "projects" would one have that would necessitate different connection structure, etc? That almost sounds like the division would be at the "application" level.

Well, as you noticed from Sunil's talk, it is a "some folks do it this way and some folks do it that way" kind of thing. There is no one right answer and I'm not even sure that there is a clear set of guidelines.

E.g., in working with my application code pre OEA I tended to have a rel directory for released source, a tst directory for code currently being tested, i.e., QA, and a dev directory for the developer working on stuff that was not yet released. That translates pretty well into three OEA projects, each with their own database and PROPATH characteristics.

But, in working on OO architectural ideas and the like, a project for me has been more ... well ... a project. Something that has internal cohesion, but does not have a lot to do with anything else. In that same sense, a developer working on multiple simultaneous tasks might create multiple projects instead of a single dev project.

Workspace I tend to use for major separations, e.g., between application code and architecture code or working on some exploration that I might throw away at the end. E.g., during the 10.2A beta I put all the sample code in a project in its own workspace (turned into a bit of a headache since the code was set up for being each sample in its own project, but that is another story) because I figured that whole workspace would only have a limited lifespan.

Workspace I tend to use for major separations, e.g.,

between application code and architecture code or

working on some exploration that I might throw away

at the end. E.g., during the 10.2A beta I put all

the sample code in a project in its own workspace

(turned into a bit of a headache since the code was

set up for being each sample in its own project, but

that is another story) because I figured that whole

workspace would only have a limited lifespan.

Having just watched the presentation on setting OEA preferences, finding out that bindings and other customizations are workspace-specific(!) and any customizations need to be exported / imported to propagate them across workspaces makes for even more management headaches for people who need multiple workspaces....

Ditto for associating behavior with a new extension - having to know about and hit 3 different windows in order to configure the desired behavior for a new extension is yet another pain in posterior.

There's also the "hierarchy" for setting colors..

Simply put, when setting up configurations and associations, there should be a single window where one can setup the desired configuration & behavior associations (such as editor colors, extension associations, etc). Having to hit all these various windows and hope you've got the right one "this time" is a pain, and will definitely slow adoption of the tool.

I think that actually the copying of preferences from one workspace to another is one of the things that needs documenting. I suspect it isn't as hard as it sounds.

Removed content and reposted under preferences discussion

Message was edited by:

Matthew Baker

Which can be found here:

http://www.psdn.com/library/thread.jspa?threadID=13513&tstart=0

I think that actually the copying of preferences from

one workspace to another is one of the things that

needs documenting. I suspect it isn't as hard as it

sounds.

Copying the preferences isn't the issue I'm concerned about - it's keeping them in sync, much like any source code project.

Admittedly, if you fiddle with your preferences a lot and have a lot of workspaces, then you would have some housekeeping to do. But, I don't know how onerous it is in practice since I would expect to do 99% of my setup originally and then make subsequent changes only rarely. Also, there tends to be a somewhat sequential use of workspaces for me ... often only one per version, so that some kind of significant transition was required moving to the new version anyway.

If you consider that you might want to have separate workspaces for say 10.2A production and 10.2B beta going at the same time, one couldn't really use a registry type approach very well since there would either be conflicts or they would need to be separate anyway.

Matthew's recent posting on exporting preferences reminds me that there is a lot about using OEA where a small piece of information stands between a user having a good experience and being frustrated. OK, maybe they are sometimes still frustrated, but manageably frustrated instead of terminally frustrated. Putting little titbits in the manual or help system is certainly a good idea, but I don't think it is really enough to optimize access. After all, how many people actually read manuals thoroughly?

I don't know how exactly one would do this in the context of Jive, but I know that with Drupal the natural structure would be book pages on topics collected into categories, similar to what Jurjen did with the Win32 reference when he moved it to the Hive. This way, one can have small, very targeted little entries mixed in with the occasional whitepaper and code samples or whatever for the topics deserving more volume. One advantage of the Drupal book pages over what I see in Jive as manifest at PSDN is that only the top page needs to show up in the site map navigation. So, there is one places to look "OEA Tips and Techniques" and once one gets there, one sees a table of contents by category and can drill down as deeply as one needs to provide structure to the material.

We'd be very happy to host such a thing on OE Hive, but certainly some of the material is already up on PSDN and some of the most likely contributers would be PSC staff, so I don't suppose that idea will fly very well. But, I do think such a thing could make a major difference in ease and success of adoption. I quite like the idea of multiple contributors and little factoids like this business of how to move preferences wholesale. If I try to remember this in 6 months, am I really going to be able to find it easily in the forum posts?