News:

  • June 10, 2026, 08:05:13 AM

Login with username, password and session length

Author Topic: Document editor  (Read 15323 times)

PLCGuy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 677
Document editor
« on: August 18, 2016, 11:20:33 AM »
Little quark in using the Documentation Editor.
Am I using it wrong?
Hitting Cntrl "D" brings up the Editor. Unlike DL it is basically blank. I added X0-X15 and Y0-Y15. Saved it. Closed the program. Opened it again to work on it.
Went back into the editor and the X's and Y's that I had blank did not show up. How can I keep the blank ones so later I can go and fill them in?
I do notice if I go into the program and enter one of the blank ones, like X2 in my case. Don't label it. I went back to the document editor and there it was, blank of course.

I would like to keep my blank ones when I add a whole series, so I can go back in and label them before I program. If not, when I go back to the editor I have to add them again.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6158
  • Yes Pinky, Do-more will control the world!
Re: Document editor
« Reply #1 on: August 18, 2016, 11:49:14 AM »
Do-more's documentation is different than DL in two big ways: 1) the potential number of things that can documented is *huge*, and 2) you aren't documenting a memory location, but actually anything that can be referenced in the program, like a cast or structure field. Trying to blow out every possible documentable thing would have resulted in millions of lines in the editor, which is simply unmanageable, so we went to a more record-cetric approach for Do-more. As you've now observed, the downside is that by default there is nothing there.

To make it a little friendlier, we added the concept of virtual records. Any time a documentable reference is used in the program, we add a virtual record to the database. Virtual records are indicated by the '*' next to the element reference. We also made it possible to add virtual records through the "Add" option, which is what you've done. The reason they aren't there when you come back in is because the records don't actually exist in the database. At first glance it would seem pretty easy to create empty records instead of virtual records, but emptying the record is what tells the database system to delete the record.

It isn't a great workaround, but you could so something like using the "Add" option in single record mode, setting the Nickname field to something like Dummy0, checking the "Keep record content..." option at the bottom, and just keep hitting the "Add Record..." button to stream down through memory. That will create real records and initialized them to Dummy0, Dummy1, Dummy2, etc.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

PLCGuy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 677
Re: Document editor
« Reply #2 on: August 18, 2016, 12:26:16 PM »
So even if I add records, they are not "real" to the system if I leave the fields blank. Is it too much to ask if adding a RANGE, to make them real so they stick?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6158
  • Yes Pinky, Do-more will control the world!
Re: Document editor
« Reply #3 on: August 18, 2016, 12:35:01 PM »
So even if I add records, they are not "real" to the system if I leave the fields blank. Is it too much to ask if adding a RANGE, to make them real so they stick?

Too much to ask? No, it's a reasonable request, but it fights with some aspects of the design as it exists now. In the current design, the way you delete a record is by storing an empty record. I can probably find a way around it, but was just explaining why it isn't as simple as you would think. The only way to make it completely foolproof is to force the user to explicitly delete records, and eliminate the implicit delete. That would make you happy, but might annoy 100 other people, and that is something we try hard not to do.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

plcnut

  • Hero Member
  • *****
  • Posts: 814
    • premiersi.com
Re: Document editor
« Reply #4 on: August 18, 2016, 12:53:24 PM »
I like the way that the documentation editor currently functions. It keeps things clean.
I only manually add to the documentation database when I am going to be actually entering the documentation. I have also ceased using any X's, Y's, WX's, or WY's in my program blocks. I now use the $TopOfScan to MOVE(R) all my inputs to internal memory, and then use $BottomOfScan to MOVE(R) all my internal memory to the outputs. This has allowed me to not get caught up with all the correct labeling of I/O when I am building the program. I try to use a practical name and I enter most of them directly into the instruction and assign them to the elements as I go. I can then assign physical I/O at the very end when all of the actual modules have been spec'd.
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

Mike Nash

  • Hero Member
  • *****
  • Posts: 652
Re: Document editor
« Reply #5 on: August 18, 2016, 02:49:09 PM »
I have found if I am going to be assigning a range for a particular section of code (Entry End, Exit End, etc.) I can just put that category descriptor into Extra Info and that holds them for me (and helps me locate things later too.)

PLCGuy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 677
Re: Document editor
« Reply #6 on: August 19, 2016, 07:14:09 AM »
Thanks for the tips. Will try the extra info

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6158
  • Yes Pinky, Do-more will control the world!
Re: Document editor
« Reply #7 on: August 19, 2016, 01:17:59 PM »
We've talked about it and kinda like the idea of making it an option (from the Add Record dialog) to create records with a special internal flag that will prevent deleting them even if empty. They can still be deleted by selecting the record row and pressing delete, but clearing the content won't delete them. This should allow it to work like it has, and still support what you want.

The other thing we like is to add an optional Extra Info and Description field that will let you specify some content to initialize those fields to when you've chosen to add real records instead of virtual ones. Worst case, we use this feature instead of the flag above to create real records, and simply force you to stick something in either the Extra Info or Description field.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

PLCGuy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 677
Re: Document editor
« Reply #8 on: August 21, 2016, 09:35:58 PM »
I love the way HostEng considers, and talks things over when you see a request. Not sure of any other company that does that.

plcnut

  • Hero Member
  • *****
  • Posts: 814
    • premiersi.com
Re: Document editor
« Reply #9 on: August 21, 2016, 10:59:11 PM »
I love the way HostEng considers, and talks things over when you see a request. Not sure of any other company that does that.
"Liking" this post.
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

PLCGuy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 677
Re: Document editor
« Reply #10 on: August 22, 2016, 06:28:21 AM »
Just one more thought. If the blanks in the range were made to stay, it also reflexes what is in the rack. If I need to modify the program and need for an example another x input. I can visually see by bringing up the editor and seeing what is available. Of course I would do a FIND to make sure the blank X in not being used and I did not forget to label it. Just another quick tool. There is the cross reference of course, but I find the Editor faster to see what is being used.