Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Bolt on June 04, 2019, 11:56:42 AM
-
I'm trying to Import Element data from a CSV with casted elements, N400:0-7, etc, and the casted elements aren't getting their names. Is there a trick to this? I've tried it with quotes around all cells and without, both ways don't work.
-
Here's some screenshots
-
Here's some screenshots
I was able to duplicate it. Should be relatively easy to fix.
In the mean time, I think it may work if you move the non-cast nicknames to the bottom of the file:
"N400:0","RingoA","",""
"N400:1","RingoB","",""
"N400:2","RingoC","",""
"N400:3","RingoD","",""
"N400:4","RingoE","",""
"N401:0","GeorgeA","",""
"N401:1","GeorgeB","",""
"N401:2","GeorgeC","",""
"N401:3","GeorgeD","",""
"N401:4","GeorgeE","",""
"N400","Paul","",""
"N401","John","",""
Or if you already have NN for the non-cast, it may not import.
I figured out the issue. The default priority for Import Behavior is Merge (Project Priority). When you import N400 nickname of Paul, N400:0 has an implicit nickname (not explicit, though) of Paul:0, so when it tries to import the NN RingoA for N400:0, it thinks it already has a NN for it (implicit Paul:0 however), hence it does NOT import RingoA. It needs to import EXPLICIT OVER IMPLICIT when Import Behavior is Merge (Project Priority), which it is not currently doing
So, ANOTHER work-around for now is to tweak the Import Behavior to Merge (CSV File Priority), although that may GIVE YOU NICKNAMES YOU DON'T WANT, since this will also redefine any EXPLICIT nicknames giving CSV File Priority (you may not want that).
-
Thanks.
I had to:
Delete all nicknames in the block of elements
Filter my sheet by contains ":"
Import that
Filter my sheet by does not contain ":"
Import that
All done.
A glitch, but at least you could give me a work around. I don't mind finding and documenting glitches, but this company does something about it, and informs the user, both in a timely manner. I don't run into that allot...
Thanks!
-
There is probably a similar issue with structure fields, I'm sure, since structure fields can also have implicit nicknames.
For example:
T0, "CookTime"
// at this point in time, T0.Acc has the implicit nickname "CookTime.Acc", and T0.Done has the implicit nickname "CookTime.Done"
T0.Done, "BatchDone" // explicit nickname for T0.Done - won't import with Merge (Project Priority) since T0.Done has an "implicit" nickname. :-\
-
All done.
Good!
A glitch, but at least you could give me a work around. I don't mind finding and documenting glitches, but this company does something about it, and informs the user, both in a timely manner. I don't run into that allot...
Thanks!
You are welcome. We have discovered that if you provide a work-around, most customers are happy to move on and get THEIR work done (but I still have mine ;D). Like I said, it should be an easy fix.
-
Fixed. It will be in the next release.
(wasn't as simple as I hoped - I found some other issues regarding error reporting, et. al. and cleaned those up also)
-
There is a similar problem when trying to create nickname on the fly. If N1 has a nickname and then I try to create a unique nickname for N1:0, it will say that element is already used. My work around is go into the documentation editor and add it there. Works, but slows me down.
-
There is a similar problem when trying to create nickname on the fly. If N1 has a nickname and then I try to create a unique nickname for N1:0, it will say that element is already used. My work around is go into the documentation editor and add it there. Works, but slows me down.
Undoubtedly the same problem. We'll get it fixed.