Documentation of Bits

[JeffS]

So I have an issue where say I have V2 and I nickname it "HtrPB_BitsFrom_1" and I then need to create and use v2:0 and v2:12.  When I initially add these to the documentation they get "nicknamed" HtrPB_BitsFrom_1:0" and "HtrPB_BitsFrom_1:12".  I don't want to actually nickname these so I leave them be, but I wanted to add some Extra Info "Run Mode ON" and "Error Exists" respectively.  As soon as I add the Extra Info the Nicknames change to "HtrPB_BitsFrom_1" and the program goes on about its day without any issues and retains my Extra Info entered. 

The problem I have is if I export documentation I can't import that same documentation because the nickname is no longer unique.  If I try to delete this duplicate nickname the Extra Info is replaced with 0.  Then I can't add the Extra Info back until I give it a unique nickname.  So as things have gone as I come across these I have been forced to generate nicknames which really aren't that helpful because the nickname isn't long enough to give context "HtrPB_BFrom1_B0" and is why I normally just use the Extra Info or Description that doesn't have to be unique.  Is there any reason that I couldn't just leave these without nicknames like any other element normally, and still give it Extra Info or Description? 

Running Domore 2.9.4

Thanks,
Jeff

[franji1]

I just tried this with 2.9.4.  The "implied" casting nicknames stayed as-is - I did not get any underscores when I just modify the Extra Info Cell.

Then when I exported Element Documentation as Standard or Standard Plus, the root V0 has a NN, and all the bit casts NN are empty, but the Extra Info and Description columns remained intact.  I've attached the export file (I had to change extension to .txt to get forum to accept it).

To help us figure it out, start with a new project and duplicate it providing the exact steps.

[JeffS]

So I opened a new project for a BX-DM1E-M-D, added some logic using the elements to the main program.  Opened the documentation after accepting the program to name these elements.  Named V1 and V2 and got the same behavior I saw in my other program. 

Attached is the document export for this new program called temp.txt.  This is what I get if I don't try and clear out the nicknames for the bits after adding the Extra Info.  If I delete the nicknames my Extra Info gets replaced with a 0 or 12 respective to the bit.  If I try and overwrite the contents of the Extra Info it gets immediately replaced by 0 and my nickname is the :0 appended nickname again.  If I clear this nickname again and try to replace the Extra Info contents again it once again gets replaced by 0 and the nickname goes to the :0 appended one.  If I leave this :0 appended nickname and edit Extra Info the Nickname changes to the same as the V2 nickname.

Looks like the issue is having a nickname long enough that appending :0 or :12 would make it overflow.  Seems the overflow characters dump into Extra Info which is why my Extra Info was being replaced with 0 (bit 0) when I attempted to delete the nickname or a 12 replacing my Extra Info contents if I attempted to delete the :12 nickname.  If I shorten my nickname to 3 less than max, or 2 for single digit bits, then it works like it should.  Problem is I need all the characters to so that my nicknames sorta make sense.

Let me know if this is clear as mud.

[franji1]

I duplicated something like it in 2.9.4.  I created a 16 character nickname for V1, but also had V1:5 used in my program, so there was an implied nickname for that with V1's nickname and ":5" appended to the nickname field from V1.

I then edited V1:5 Extra Info field and the nickname for it CHANGED from "HtrPB_BitsFrom_1:5" to just HtrPB_BitsFrom_1 (matching the NN for V1).

I tried it with my development of 2.10 and it's behaved differently.  The V1:5 implied nickname did NOT show up, but when I edited V1:5 Extra Info, V1:5 Nickname DID become V1's nickname with :5 appended, BUT ALSO the Extra Info changed from what I typed to "5".

We'll figure it out.

[JeffS]

Thanks for looking into it!

[franji1]

Sorry I did not respond sooner.  This has been fixed and will be in 2.10