Om moeren en ringen correct te kunnen combineren in lijsten kunnen moeren en ringen nu binnen een boutsamenstelling in de Template Editor worden gescheiden.

In templates van de Template Editor worden moeren en ringen binnen een boutsamenstelling niet meer in één regel gecombineerd. Wanneer een boutsamenstelling voorheen verschillende moeren en/of ringen had, werd het aantal hiervan gecombineerd, maar kon geen onderscheid worden gemaakt tussen de diameters en de standaards van de moeren en ringen. Het resultaat was dat in het boutinformatierapport ringen niet werden gecombineerd.

Als moeren en ringen niet hetzelfde zijn in een boutsamenstelling, kan de Template Editor deze in templates scheiden. U hoeft niet langer NUMMER 1 - NUMMER 3 te gebruiken in de regel eigenschapsvoorwaarden voor moeren en ringen. Hierdoor kunnen moeren en ringen van meerdere boutgroepen correct worden gecombineerd of gescheiden. In de onderstaande afbeelding kunt u zien dat ringen worden gecombineerd hoewel ze verschillende grootten hebben.

Als u deze wijziging in uw eigen templates wilt zien, moet u de templates bijwerken. De boutinformatielijst (TS_Report_Inquire_Bolt.rpt) bevat de oplossing al.

Deze verbetering werd in Tekla Structures 2024 SP1 al geïntroduceerd.

In Tekla Structures, versie 2025, is de Templatebibliotheek bijgewerkt. De volgende verbeteringen zijn doorgevoerd:

• Definieer in de Template Editor zowel Betekenis als Eenheid voor waardevelden, als u geen standaardeenheid wilt gebruiken voor de betekenis. Vroeger was de eenheid niet altijd correct. In sommige gevallen werd voor de Lengte bijvoorbeeld meters gebruikt als standaardeenheid.

  

• Wanneer u sorteren gebruikt in een waardeveld (Volgorde is ingesteld op Oplopend of Aflopend) en de instelling Bij gecombineerde rows is ingesteld op Waarden optellen door alle rows of Waarden binnen 1 row optellen, gebruikt de sorteerfunctie nu gecombineerde waarden. Voorheen gebruikte de sorteerfunctie niet-gegroepeerde waarden.

• Wanneer GetFieldFormula verwees naar een waardeveld waarvoor een combineeractie Bij gecombineerde rows was geselecteerd, retourneerde dit een niet-opgetelde waarde. Dit probleem is nu opgelost.
• In grafische templates berekenen de functies Sum() en Count() nu alleen kolomwaarden als ze worden gebruikt in tabelvoetteksten. Vroeger retourneerde Count() bijvoorbeeld altijd het aantal cellen (ofwel rijen) in de hele tabel. Alle tabelvoetteksten hadden dan hetzelfde aantal. In een tabel met 3 kolommen en 4 rijen, waarbij de eerste 2 kolommen 4 cellen hadden en de laatste kolom 3 cellen, werd vroeger de waarde 11 geretourneerd in alle tabelvoetteksten. Nu hebben de eerste twee tabelvoetteksten de waarde 4 en de laatste voettekst de waarde 3.
• Een geformatteerde waarde overschrijft een waardeveld altijd, zelfs als het gegevenstype van het waardeveld Getal is (de geformatteerde waarde is altijd een tekenreeks).
• Soms werd bij het gebruik van Engelse eenheden de waarde 0 ten onrechte weergegeven als 0,0. Dit probleem is nu opgelost.
• GUID's worden nu correct gesorteerd.
• Negatieve nummers die als tekenreeksen worden weergegeven, worden nu correct gesorteerd.
• Als in grafische templates inhoud van een waardeveld daadwerkelijk binnen de grenzen van het waardeveld past, wordt deze niet afgekapt, zelfs als de inhoud langer is dan de gedefinieerde veldlengte.
• In grafische templates werkt de functie voor automatische grootte van het lettertype van het waardeveld (Wijziging lettertypegrootte in Vrije attributen) nu nauwkeuriger. Vroeger kon een iets te grote lettergrootte worden geselecteerd.
• De oplossingsvolgorde van waardeveldformules is nu correct en wordt niet meer vermengd met de tekeningvolgorde.

  De tekeningvolgorde is hetzelfde als de volgorde van de waardevelden in de inhoudsbrowser. De oplossingsvolgorde wordt bepaald door de formules in de waardevelden. Een waardeveld dat naar een ander waardeveld verwijst (bijvoorbeeld met GetFieldFormula of CopyField) wordt dus altijd opgelost nadat het waardeveld waarnaar het verwijst is opgelost.

• Voor de functie fvf is de vijfde parameter nu ook beschikbaar in tekeningtemplates en gebruikerscomponenten. Als deze is ingesteld op TRUE, worden lege items van de regel die in het bestand wordt gelezen, meegenomen wanneer de functie wordt opgelost. Als deze ontbreekt of is ingesteld op FALSE, worden lege items verwijderd.

  

  Hieronder volgen enkele hypothetische voorbeelden die illustreren hoe de syntaxis in de fvf-formule verschillende resultaten genereert, inclusief het gebruik van een vijfde parameter in de formule om lege kolommen te retourneren.

  In dit voorbeeld wordt een invoerbestand gespecificeerd met de naam sample.dat en de regel:

  A; B;; C; D

  In dit geval retourneert de formule

  

  een lege tekenreeks: ""

  Omdat elk scheidingsteken in het bovenstaande voorbeeld betekenis heeft, is de derde kolom een lege kolom tussen het eerste scheidingsteken ';' en de eerste spatie ' '. In dit geval zijn de kolomwaarden dus:

  1: "A"

  2: " B"

  3: ""

  4: " C"

  5: " D"

  en

  
  

  retourneert: "C"

  In het volgende voorbeeld worden in het invoerbestand meerdere scheidingstekens gebruikt, zoals een combinatie van spaties en komma's.

  A, B, C, D

  In dit geval retourneert de formule:

  
  

  de volgende uitvoer: "B"

  en

  
  

  een lege tekenreeks: ""

  en

  
  

  geeft de volgende uitvoer: "C"

  en tot slot geeft

  
  

  de volgende uitvoer: "D"

  Wanneer de laatste parameter is ingesteld op FALSE, worden opeenvolgende scheidingstekens geïnterpreteerd als één scheidingsteken.

  TRUE = lege kolommen toegestaan. Opeenvolgende scheidingstekens worden dus behandeld als unieke scheidingstekens.

  Meer informatie over de functie fvf vindt u in fvf.