LL_FCTPARATYPE_DRAWING und LL_FCTPARATYPE_BARCODE in ILlXFunction

Leider finde ich keine Beschreibung, wie die Parameter- und Rückgabe-VARIANTS für die Datentypen LL_FCTPARATYPE_DRAWING und LL_FCTPARATYPE_BARCODE ausgelesen / bestückt werden müssen.

Habt Ihr da einen Tipp, wo ich nachsehen kann?

Hallo Michael,

vielen Dank für deine Frage. Eigene Funktionen können derzeit nicht mit diesen Typen verwendet werden. Du könntest für das Drawing ja ggf. mit Pfaden arbeiten. Für den Barcode müsstest du als Parameter statt mit dem Barcode selbst mit dem eigentlichen Text arbeiten.

Viele Grüße

Hallo Till,

Danke für Deine Antwort. Ist schade, aber kann ich mit leben.

Inzwischen habe ich aber diese Sorgen mit ILLXFunction:

  1. Man kann keine Funktionen ohne Parameter definieren. Man kriegt dann diesen Fehler um die Ohren gehauen: “Error in return type (expected: Number, Date, String, Boolean, Picture, Barcode, is: ).”
  2. Wenn :ILLXFunction:Execute gerufen wird, dann kommen in pnTypeRes und pnTypeResLL nicht die Typen an, die ich aufgrund meines in :GetParaTypes definierten Rückgabetyps erwarten würde, sondern die von Parameter 1. Die müssen dann jedesmal überklatscht werden.
  3. Wo wird eigentlich der Rückgabefehlerstring aus :CheckSyntax angezeigt und was soll passieren, wenn ich einen Fehler zurückmelde?
  4. Wie ist das mit den Gruppen (:GetGroups) gedacht? Da wird Plural verwendet. Also habe ich es mit einer Tab-separierten Liste versucht, das hat aber nicht funktioniert. Ein Gruppe funktioniert.

Vielen Dank und beste Grüße

Michael

Hallo Michael,

Zu 1: Laut Programmierreferenz und auch unseren Tests sollte das normal funktionieren (Beispiel Now() oder ähnliches). Was genau liefert die Funktion bei einem Versuch denn zurück?

Zu 2: Das ist unerwartet, dennoch sollte man sich hier ohnehin nicht auf die Initialisierung verlassen.

Zu 3: Die Meldung sollte im Formelassistenten auftauchen.

Zu 4: Das ist vermutlich der Namensgebung “Groups” geschuldet. Laut Doku und auch in praktischen Tests wird hier nur eine Gruppe unterstützt. Tut uns Leid für die Verwirrung! :slight_smile:

Als Orientierung nutzt du am besten folgendes Beispiel:
“C:\Program Files (x86)\combit\LL31\Beispiele\Visual C++\Designer Extension Sample Custom Functions”

Sollten sich dennoch weitere Fragen ergeben oder du einen praktischen Anwendungsfall haben, wo dies nicht wie erwartet funktioniert, bitten wir dich das einfach mal mit dem C++ Beispiel nachzustellen und uns über einen Support Case bereitzustellen. Das wäre dort besser aufgehoben. So einem langem Thread mit “tiefem Einstieg” möchte dann vermutlich doch keiner folgen :wink:

Viele Grüße

Hallo Till,

Danke, dass Du dran bleibst.

Wenn ich das von Dir genannte Beispiel modifiziere und ConvertToRoman zu einer Funktion umbastle, die keine Parameter hat, dann kriege ich den genannten Fehler. Probier es doch mal aus. Eure Beispiele funktionieren, weil Ihr die Returntypen überklatscht und weil ihr keine Funktion ohne Parameter registriert.

Viele Grüße

Michael

//================================================================================
void LlXFctConvertToRoman::FctGetParaCount(INT* pnMinParas, INT* pnMaxParas)
//================================================================================
{
*pnMinParas=0;
*pnMaxParas=0;
}

//================================================================================
void LlXFctConvertToRoman::FctGetParaTypes(INT* pnTypeRes, INT* pnTypeArg1, INT* pnTypeArg2, INT* pnTypeArg3, INT* pnTypeArg4)
//================================================================================
{
*pnTypeRes = LL_FCTPARATYPE_STRING;
// *pnTypeArg1 = LL_FCTPARATYPE_DOUBLE;
}.

Bei unseren Tests hat dies auch mit einer neuen Funktion ohne Parameter einwandfrei funktioniert; dabei konnten wir kein abweichendes Verhalten feststellen.

Die von dir genannte Meldung im Designer ist relativ generisch und weist darauf hin, dass List & Label den zurückgegebenen Wert nicht verarbeiten kann. Mit ToString$() lassen sich an dieser Stelle zusätzliche Informationen anzeigen (z. B. <unknown> oder null). Um auch das von dir genannte Sample ohne Parameter ausführen zu können, müssen lediglich die entsprechenden Zeilen ergänzt werden (siehe markierter Bereich).


.
.
.

Für die weitere Analyse deiner eigenen Funktion ist es erforderlich, einen Case über das Supportportal zu erstellen: Bitte füge dort dein Projekt bei, damit der Sachverhalt gezielt geprüft werden kann.

Hallo Till,

ich hab es jetzt am Laufen. Danke sehr. Aber erklär mir bitte 2 Dinge als nicht C++ -Profi:

Wieso heißt das Ding “CheckSyntax” wenn die Syntax vom L&L schon gecheckt wurde (sonst wäre ja der Call nie angekommen) und wenn der Typ des Rückgabewertes immer aktiv gesetzt werden muss? Sollte die Funktion dann nicht besser “CheckParametersAndPositivelyAdviseReturnType” heißen?

Im Beispiel findet man zweimal dies:

//================================================================================
INT	????::FctCheckSyntax(CString& sError, INT* pnResType, UINT32* pnLLType, UINT* pnDecs, UINT nArgs, VARIANT VarArg1, VARIANT VarArg2, VARIANT VarArg3, VARIANT VarArg4)
//================================================================================
{
return (0);
}



und das ist die Standardimplementierung der Interface-Methode:


//================================================================================
STDMETHODIMP LlXFct::CheckSyntax(BSTR* pbsError, INT* pnResType, UINT32* pnLLType, UINT* pnDecs, UINT nArgs, VARIANT VarArg1, VARIANT VarArg2, VARIANT VarArg3, VARIANT VarArg4)
//================================================================================
{
	CString	sError;

	if (FctCheckSyntax(sError,
			pnResType,
			pnLLType,
			pnDecs,
			nArgs,
			VarArg1,VarArg2,VarArg3,VarArg4) < 0)
	{
		*pnResType = -1;
		SysReAllocString(pbsError, _bstr_t(sError));
		return(E_FAIL);
	}
	return(S_OK);
}

Ich würde daraus schließen, dass ich einfach S_OK aus der Interface-Methode zurück geben muss, wenn es keine falschen Parameter geben kann. Aber dann tritt der von mir genannte Effekt auf.

Beste Grüße

Michael