Project

General

Profile

Actions

Support Request #4812

closed

Support for NSSUBPROP_HIDDEN in ADTF 3.x

Added by hidden over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Customer:
VW
Department:
Requester's Priority:
Normal
Support Level:
2nd Level
Resolution:
Solved Issue
Product Issue Numbers:
Affected Products:
Platform:
Topic:
ADTF::SDK
FAQ Links:

Description

Supportanfrage

Geht das noch irgendwie?

Lösung

Eein Hidden kann man auch in ADTF 3 noch machen, aber eben nicht über eine property_variable. Sondern ganz einfach über ein

auto hidden_value = get_property<tInt32>(*this, "my_hidden_property", 1234 /*default*/);

Also die Property nur auslesen, aber nicht selber im Konstruktor setzen. Dann muss man sie natürlich händisch in der .adtfproperties hinzufügen (so wie in ADTF2 auch), danach glaub ich sollte sie sogar im CE erhalten bleiben.

Actions #1

Updated by hidden over 5 years ago

  • Status changed from New to In Progress
  • Topic set to ADTF::SDK
  • Customer set to VW
Actions #2

Updated by hidden over 5 years ago

@Sebastian: Bitte wie besprochen bearbeiten

Actions #3

Updated by hidden over 5 years ago

Hallo Timo,

hier auch nochmal Entschuldigung für die späte Antwort.

Wir haben NSSUBPROP_HIDDEN in ADTF 3 in frage gestellt und deshalb nicht umgesetzt. Welchen UseCase hast du für ein verstecktes Property?

Actions #5

Updated by hidden over 5 years ago

  • Status changed from In Progress to Customer Feedback Required
Actions #6

Updated by hidden over 5 years ago

Sebastian Geißler wrote:

Hallo Timo,

hier auch nochmal Entschuldigung für die späte Antwort.

Wir haben NSSUBPROP_HIDDEN in ADTF 3 in frage gestellt und deshalb nicht umgesetzt. Welchen UseCase hast du für ein verstecktes Property?

Das Hidden-Flag wurde dann verwendet wenn man eine Property nur zu DEBUG zwecken angeboten hat.

D.H. Der Entwickler geht ins Auto und probiert diverse Settings aus. Das ist leichter als immer wieder den Code neu zu bauen und dann ins Fahrzeug zu bringen.
Daraus resultiert am Ende beispielsweise ein Wert X. Dieser wurde dann als default Value verwendet und die Property auf hidden gesetzt.
Alternative wäre gewesen den Property-Call gar nicht mehr zu machen jedoch wurde die Property zum erneuten Testen immer mal wieder auf sichtbar gestellt.

Actions #7

Updated by hidden over 5 years ago

  • Status changed from Customer Feedback Required to In Progress
Actions #8

Updated by hidden over 5 years ago

Dann würde ich die Property auch nur für Debug-Builds verwenden, damit wäre sie auch nur in der Debug Plugindescription und im release "unsichtbar" da nicht vorhanden.

Actions #9

Updated by hidden over 5 years ago

Was meinst du, Sebastian ?

Actions #10

Updated by hidden over 5 years ago

Florian Roth wrote:

Dann würde ich die Property auch nur für Debug-Builds verwenden, damit wäre sie auch nur in der Debug Plugindescription und im release "unsichtbar" da nicht vorhanden.

Ein wirklicher Debug-Build kommt für die Entwickler nicht in Frage denn bei den meisten Projekten ist die Laufzeit von extremer Relevanz. Debug Builds sind mit Abstand langsamer. Was man aber auf jeden Fall machen könnte ist eine Präprozesserdefinition zu verwenden.
Ich bin mir gerade aber nicht sicher: liest nicht ein hidden property nicht trotzdem die Konfiguration der system.xml aus und wird einfach nur nicht angezeigt? Ich kann mir vorstellen, dass diverse Entwickler auch hierauf setzen und die Werte dann nicht im im Code definieren sondern die im Testumfeld eingestellten Werte aus der XML erwarten.

Ich habe am Monatag ein Meeting zum ADTF3 Thema und werde das hier mal kurz ansprechen.

Actions #11

Updated by hidden over 5 years ago

  • Status changed from In Progress to Customer Feedback Required

Gut dann sind aber eure "Debugzwecke" nicht als wirkliches Debug zu verstehen, eher als Entwicklung...

Wie dem auch sei, was ihr eigentlich braucht:
Ihr lest im Filter eine Variable aus, welche aber nicht auf eine Membervariable gemappt wird, ebenso nicht in der Plugin Description steht (und damit nicht im CE angezeigt wird), wohl aber in der setzbar ist bzw. im Property File stehen kann.

@Martin: Ist das zum Konfigurationszeitpunkt (ADTF Config Tool) bzw. Laufzeit (ADTF Control) mit SetProperty möglich ?
Es "einfach" ins Property File händisch zu schreiben geht ja imho ohnehin.
Ein hidden in dem Sinne brauchen wir eigentlich in ADTF 3.x nicht mehr, um diesen Use Case zu erfüllen... liege ich richtig ?

Actions #12

Updated by hidden over 5 years ago

Ja Flo, ein Hidden kann man auch in ADTF 3 noch machen, aber eben nicht über eine property_variable. Sondern ganz einfach über ein

auto hidden_value = get_property<tInt32>(*this, "my_hidden_property", 1234 /*default*/);

Also die Property nur auslesen, aber nicht selber im Konstruktor setzen. Dann muss man sie natürlich händisch in der .adtfproperties hinzufügen (so wie in ADTF2 auch), danach glaub ich sollte sie sogar im CE erhalten bleiben.

Actions #13

Updated by hidden over 5 years ago

  • Project changed from 20 to Public Support
  • Subject changed from NSSUBPROP_HIDDEN to Support for NSSUBPROP_HIDDEN in ADTF 3.x
  • Description updated (diff)
  • Status changed from Customer Feedback Required to To Be Closed
  • Private changed from Yes to No
  • Resolution set to Solved Issue
Actions #14

Updated by hidden over 5 years ago

  • Status changed from To Be Closed to Closed
Actions

Also available in: Atom PDF