Designer Objekt mit Variablenbindung

Hallo,

ich habe ein eigenes Designerobjekt als Erweiterung für List&Label geschrieben.
Zurzeit verwende ich ListLabel14, mit der ListLabel14.dll.
Meine Daten beziehe ich aus einem DataSet.

Das Objekt enthält ein ObjectProperty “customer” in der der Spaltenname gespeichert wird. (z.B: Table.Customer)
Im DrawDesignerObject-Event lese ich den Inhalt wie folgt aus:

m_listLabel.Core.LlGetVariableContents((string)obj.ObjectProperties[“customer”])

Jedoch bekomme ich hier eine Fehlermeldung, dass die Variable mit diesem Namen nicht vorhanden ist. Wenn ich jetzt aber ein Textfeld mit dem Wert aus der Spalte befülle, dann ist die Variable vorhanden und das eigene DesignerObject wird richtig dargestellt.

Gibt es etwas, das ich beachten muss wenn ich die Daten über diese Methode auslese.
Oder hat es ganz einfach etwas mit der verwendeten Komponente zu tun, muss ich die ListLabel14VS2005.dll verwenden?

“Daniel Wonisch” <Daniel.Wonisch@autforc…> schrieb im Newsbeitrag
news:4259556200914316@combit.net…

ich habe ein eigenes Designerobjekt als Erweiterung für List&Label
geschrieben.
Das Objekt enthält ein ObjectProperty “customer” in der der Spaltenname
gespeichert wird. (z.B: Table.Customer)
Jedoch bekomme ich hier eine Fehlermeldung, dass die Variable mit diesem
Namen nicht vorhanden ist.

Hm, das Problem duerfte sein, dass hier gar nicht bekannt ist, dass die
Variable Table.Customer ueberhaupt gebraucht wird (das weiss ja nur Dein
Code, fuer LL ist es schlicht ein String mit Inhalt “Table.Customer”), die
daher nicht als verwendet gekennzeichnet wird und dann zur Druckzeit gar
nicht angemeldet wird. Kannst Du die Variable auch z.B. zusaetzlich als
Benutzervariable eintragen? Dann sollte es gehen.

G.

Danke für den Vorschlag, die Verwendung einer Benutzervariable ist ein ähnlicher Workaround wie mit dem Textfeld.

Irgendwie müsste man List&Label auch sagen können, dass die benutze Variable bei diesem Objekt in Verwendung ist.
Es sei denn, die benutzerdefinierten DesignerObjekte sind nicht auf diese Art Erweiterungen ausgelegt. Zumindest sehen sie auch im Quellcode des Reports anders aus.

Ich habe die Lösung in einem Artikel der englischsprachigen Newsgroup gefunden.

Man kann die Variable mit LlExprParse im ReportFile anmelden.