Search\Replace for Documentation Editor

[ATU]

Has there been any thought for adding a simple search and replace "text" feature in the documentation editor?  I was working on a machine that had 2 identical parts. It would have been nice to highlight a range of cells, searched for "Side 1" and replaced every instance in that range with  "Side 2"  in both the Nickname and Description fields. I know you can export to Excel and do it, but its a lot to do for only a small range of addresses.

[BobO]

Thought? Sure. Actual work? No, but we're thinking about it. <rim shot> Thanks! I'll be here all evening!

Seriously...it is needed. We'll look at it.

[Controls Guy]

Just get the Excel thing to work well, including fields-per-line, and you're done.  When I do a SLC project over maybe 25 I/O, the Excel copy of the docs is actually the controlling copy, with only imports to RSLogix.

[ATU]

25?  That's what I'm talking about.  More than a page worth of data or complicated  changes and it's worthwhile to do the Excel thingy. I would like to highlight a range of cells, do my changes quickly and move on.

[Controls Guy]

25?  That's what I'm talking about.  More than a page worth of data or complicated  changes and it's worthwhile to do the Excel thingy. I would like to highlight a range of cells, do my changes quickly and move on.

Exactly.  In my other post I was just telling Bob that if they made the Excel export/import work properly, they wouldn't have to worry about writing the search and replace themselves.

[ATU]

Although, most people would have it on their PC, can you take it for granted that every user would have Excel?

[Controls Guy]

Although, most people would have it on their PC, can you take it for granted that every user would have Excel?

No, but it's not really critical.

First, Search and Replace in Docs is non-mission-critical enough that the two percent or whatever that don't have it can do their Docs edits in the Docs editor.

Second, Open Office Calc will do pretty much everything Excel does and it's free.  I use it almost every day.  Besides I wasn't entirely clear when I said "Excel" import/export.  I didn't mean an Excel format file per se but a file in a format most people would choose Excel to edit.  Actually, I wouldn't really advise an XLS or true Excel import/export, but rather a CSV, which is just a text file with commas in it and you can manipulate it with Notepad, or Wordpad, or who knows, theres probably a Windows version of emacs if you really want.

So, no, I don't see the slightly-less-than-ubiquitous presence of Excel as a problem.

[Controls Guy]

Incidentally, BobO, as long as the project format is multifile, what's the advantage of not having the Docs editor store NATIVELY in CSV or DIF or other open format?

If at some point you go to single-file projects that would become moot, but if it's multiple files anyway, why not?

[BobO]

In the current context, the file is actually a relational database...a CSV really isn't possible without a major DB change. I don't see us changing that in existing DSP very quickly, although we would still like to. In the new DSP for the new CPU, it is a single file as you mentioned. We do expand into multiple temp files, and the temp format could in fact be CSV, with very little effort...but there isn't a real benefit for it to be.

Sadly, the new import/export will be a bit more restrictive then in the past, due to the need to maintain a memory map with the program and docs. Not sure what that will translate into from your perspective, but we will try an be as flexible as possible knowing that folks like to use Excel and such.

[Controls Guy]

Not sure what that will translate into from your perspective, but we will try an be as flexible as possible knowing that folks like to use Excel and such.

I don't know that it's quite right to say that we like to use Excel so much as that we DON'T like to use the doc editing tools provided with most PLC programming packages.  Try drag-and-fill in RSLogix.  Try doing cells that relate to other cells and thus compute their own values rather than have them typed in literally in DirectSoft.  Just "ain't gonna happen".

Now I don't know that that's a problem per se as there are many good table editing tools available (Excel, Calc, Wordpad, etc), and the pool of PLC-programming-software coding talent is much dearer than guys who can (and already have) written spreadsheets.  So the man hours you guys have to spend will have far more impact on overall user experience if you spend them doing PLC related stuff than trying to recreate what already exists, and is in fact already installed on 98% of the computers running DirectSoft.