Hallo,

Ich möchte im Listenmodul in einer Spalte anzeigen, ob der Schlusskurs einen gleitenden Durchschnitt in den letzten x-Tagen von unten nach oben geschnitten hat und im "True"-Fall das Wertefeld grün einfärben.

Bis auf das Einfärben funktioniert das alles mit folgender Formel:

Signal := crossdays (close,mov(close,Para1,s),Para2);
Result1 := Signal;
Backcolor := if(Signal = True,Green,Red);

Die möglichen Signale "True" und "False" werden korrekt angezeigt, nur das Einfärben des Hintergrundes will nicht funktionieren.

Ich bin mir bewusst, dass "crossdays" im Kern für Filter und Handelssysteme gedacht ist, aber ich möchte die Information nun einmal in einer Liste haben.

Kann mir jemand einen Hinweis geben?

---

Mit freundlichen Grüssen

Uwe Michalowski

Hallo Uwe,

Du erzeugst das Signal und dann erst die Farbegebung.
Setze einfach mal das Result ans Ende, dann sollte es gehen.
Zumindest hat´s bei mir gelangt.

Schöne Grüße aus Rio
Steffen

Hallo Steffen,

Auch der Tausch Ergebnis/Farbgebung hat nicht zur Anzeige der Farbgebung aus der Formel geführt. Ich kann da jetzt auch nichts mehr feststellen, oder gibt es BackColor zur Steuerung des Spaltenhintergrundes in dieser Form nicht mehr?

Wie in der Antwort an Hr. Rohmann beschrieben, habe ich meine Anforderung anders gelöst. Ich bin damit zufrieden.

---

Mit freundlichen Grüssen

Uwe Michalowski

Hallo Steffen,

Das geht bei mir so überhaupt nicht. Weder wird ja/nein angezeigt noch werden die Felder eingefärbt. Ich habe Deine Codezeilen einfach nur kopiert, da kann nicht schief gegangen sein.

Wie hier schon beschrieben habe ich mein Thema anders gelöst: Das Signal als 1/0 ausgegeben und dann im Listenmodul die Farbe ausgewählt. Das geht natürlich problemlos.

Ich bin absolut Pragmatiker und mein Problem ist gelöst : aber mich würde doch interessieren wie bei Deiner Formel ein ja/nein zustande kommt, in der Formel kann ich jedenfalls nichts entdecken und der Standard ist ja wohl True/False und wird bei mir auch so angezeigt. Zum anderen ist es natürlich grundsätzlich unbefriedigend in meiner Installation die Farben nicht über Formeln einstellen zu können. Das hat ja schon Vorteile. Liegt es an der Version - ich habe TaiPan EOD 14? Oder gibt es irgendwelche Einstellungen die ich evtl. "verbogen" haben könnte oder die bei Dir anders eingestellt sind?

Aber das ist wohl eher ein Thema, das ich mit L&P einmal ansprechen sollte.

Jedenfalls vielen Dank für Deine Hinweise.

---

Mit freundlichen Grüssen

Uwe Michalowski

Hallo Herr Rohmann, hallo Steffen, hallo Uwe,

Sämtlich bisher skizzierten Lösungsansätze hoben zwar den überaus positiven Grundgedanken dieses Forums hervor, anderen Forumsteilnehmern bei Problemen bzw. deren Lösung mehr oder weniger helfen zu wollen, waren bisher in Bezug auf ein halbwegs greifbares Ergebnis prinzipiell jedoch nichts anderes als Kaffeesatzleserei.
Deshalb freut es mich, an dieser Stelle vielleicht ein wenig zur Eingrenzung des Problems beitragen zu können, auch wenn zum aktuellen Zeitpunkt die wahre Fehlerursache immer noch nicht exakt lokalisiert werden kann.

@ Herrn Rohmann

Meine Anmerkung zu Ihrem Beitrag würde weit über die hier zu diskutierende Problematik hinausgehen. Deshalb möchte ich diese hier einmal außen vorlassen und in einem separaten Beitrag darauf eingehen.

@ Steffen

Deine Aussagen bezüglich (der Wichtigkeit) der Reihenfolge der Codezeilen speziell bei Interpreter-Programmiersprachen (die Programmiersprache von Tai Pan ist eine solche Programmiersprache) sind prinzipiell richtig, für den hier diskutierten Fall jedoch völlig bedeutungslos.

Begründung 1: (zum Grundsätzlichen)

Zwischen dem Ergebnis selbst (bzw. seinem Wert) und der Formatierung des Ergebnisses (zwecks Darstellung in einer Liste) bestehen keinerlei Abhängigkeiten!
Es ist somit völlig egal, in welcher Reihenfolge die Codezeilen (im nachfolgenden Beispiel in Wortformeln) formuliert werden

Beispiel 1:

1. Der Wert des Ergebnisses ist "Ja".
2. Die Ausgabefarbe des Ergebnisses ist Grün.
3. Nun gib das Ergebnis in einer Listenspalte aus.

Beispiel 2:

1. Die Ausgabefarbe des Ergebnisses ist Grün.
2. Der Wert des Ergebnisses ist "Ja".
3. Nun gib das Ergebnis in einer Listenspalte aus.

Die Listendarstellung in Tai Pan - ein Analogon zur Codezeile drei -, erfolgt also erst dann, wenn alle Codezeilen bezüglich des darzustellenden Ergebnis abgearbeitet worden sind. Ob dabei erst der Ergebniswert beschrieben und dann erst seine Formatierung festgelegt wird ist hierbei völlig unerheblich. Beide Codebeispiele erzeugen das gleiche Ergebnis - sowohl in Bezug auf den Wert als auch auf die Form der Darstellung!

Begründung 2: (üblicher Standard der codemäßigen Farbgebung in Tai Pan)

Daß die Reihenfolge von Ergebniswert und Ergebnisformatierung keinerlei Rolle spielt, sollte eigentlich jeder Tai Pan-Anwender verinnerlicht haben, der sich schon einmal mit Tai Pan-Formeln beschäftigt hat, welche eine spezielle Farbgebung bei der Ausgabe von Ergebnissen vorsehen. Diese Formeln laufen dem engagierten Anwender - vom Listenmodul einmal abgesehen - z. B. bei Filterformeln im Chartmodul in der (Darstellungs-)Form von Status- und Zonenbändern permanent über den Weg.

In den Codezeilen dieser Formeln heißt es prinzipiell immer (in Wortformeln):

1: Ergebnis (Filterwertdatenreihe bzw. Signalwertreihe);
2.ColorX := WENN(Farbband größer oder kleiner Grenzwert, DANN nimm Farbwert1, SONST nimm Farbwert2);

Die dargestellte Codezeile 1 ist gleichbedeutend mit einer Codezeile Result := Ergebnis, d. h. die dargestellte Codesituation ist somit insgesamt mit der von Uwe dargestellten Codeproblematik durchaus vergleichbar. Die genannte Codezeile 1 aktiviert in den erwähnten Formeln die Farbgebung über das Farbband, während die Farbgebung selbst erst in Codezeile 2 beschrieben wird. Wichtig in diesem Zusammenhang ist: Die Farbgebung wird in allen Fällen erst nach der Ergebnisausgabe beschrieben - und die Sache funktioniert immer einwandfrei! Der Kern des eigentlichen Problems muß also woanders liegen!

Nun zum eigentlichen Kern des Problems

@ Uwe


Zunächst einmal zu den Rahmenbedingungen:

Die von Herrn Rohmann angesprochene Formel ist eine sogenannte Spaltenformel und ist sehr wohl Teil jeder "offiziellen" Tai Pan (mindestens seit Tai Pan 8!). Du findest sie allerdings nicht bei den "normalen" Tai Pan-Formeln sondern im Listenmodul! Wenn Du dort nach der Liste "Stochastic Kaufsignal" suchst und diese gefunden hast, must Du diese über den Einstellungsdialog öffnen, um die einzelnen Bestandteile (Spalten) der Liste zu sehen. Wenn Du dann die Spalte "Stochastic Kaufsignal" markierst und anschließend auf den Button "Formel" klickst, hast Du die von Herrn Rohmann beschriebene Formel vor Augen.
Findest Du die Liste "Stochastic Kaufsignal" nicht, so hast Du sie entweder versehentlich gelöscht oder aber sie steht aus unerfindlichen Gründen in Tai Pan 14 nicht mehr zur Verfügung. Letzteres kann ich nicht nachvollziehen, da ich nicht mit Tai Pan 14 arbeite und dies zukünftig aufgrund des schlechten Preis-/Leistungsverhältnisses mit Sicherheit auch nicht tun werde.
Bis zu diesem Punkt meines Beitrags ist - wenn Du besagte Liste gefunden haben solltest - davon auszugehen, daß Deine Tai Pan-Version völlig in Ordnung ist! Das Problem liegt nicht in Rahmenbedingungen wie TP-Version oder unterschiedlichen verbalen Auslegungen des Signals. Die Diskussion über "False/True" oder "Wahr/Falsch" oder "Ja/Nein" geht völlig am Thema vorbei. Diese unterschiedlichen Beschreibungen sind nichts anderes als unterschiedliche verbale Verständnishilfen ein und desselben Sachverhalts für uns Menschen. Im Inhalt der dazugehörigen Variablen im Speicher des Computers steht (in nahezu allen Fällen) immer das Gleiche: Entweder eine 1 für ein positives Ergebnis oder eine 0 für ein negatives Ergebnis!

Nun zu Deinem Code, den ich hier zur besseren Nachvollziehbarkeit noch einmal - mit Zeilennummern versehen - aufführen möchte:

1: Signal := crossdays (close,mov(close,Para1,s),Para2);
2: Result1 := Signal;
3: Backcolor := if(Signal = True,Green,Red);

Wenden wir die bisher erörterten Aspekte auf Dein Codebeispiel an, so ergibt sich folgender Sachverhalt:
Die Funktion crossdays liefert - und hierbei ist es wiederum völlig unerheblich ob die Funktion in einer Spaltenformel (Listenmodul) oder in einer Chartformel (Chartmodul) oder Filterformel (Filtermodul) eingesetzt wird - immer als Ergebnis entweder eine 1 oder eine 0 als Ergebnis zurück. Das Ergebnis - und somit auch Deine Variable "Signal" ist also vom Typ Boolean, - anders formuliert, Deine ursprüngliche Codezeile 1 ist also richtig und völlig in Ordnung. An Codezeile 2 ist nicht viel falsch zu machen - daraus folgt, daß der Code bis zum Ende der zweiten Codezeile völlig ok sein muß - dafür sprechen schließlich auch Deine Aussagen und Beobachtungen, die, soweit ich es überblicken kann, mit Ausnahme der True/False-Problematik ebenfalls alle richtig, transparent und nachvollziehbar sind.

Der entscheidende Fehler sollte also in Codezeile 3 liegen.

Was in dieser Codezeile steht, ist - bei genauerer Betrachtung - auch leider kompletter Blödsinn!

Diese Aussage ist aus Sicht des Computers zu sehen, nicht persönlich gemeint und richtet sich keinesfalls gegen Dich. Es ist nur so, daß wir Menschen zwar eindeutig zu verstehen glauben, was Du mit dieser Codezeile bezweckst bzw. bewirken möchtest - nur Dein Computer versteht Dich nicht - und das aus gutem Grund!

Was da - nicht vermeintlich sondern tatsächlich - geschrieben steht, möchte ich an einem Analog-Beispiel (in Wortformeln) verdeutlichen:

WENN ein Signal vorliegt, DANN Apfel(Green), SONST Birne(Red)). Das Ergebnis dieser IF-Funktion wird dann, um die Sache (für uns Menschen!) perfekt pseudo-verständlich zu machen, letztendlich der Variablen mit dem für Menschen durchaus "passenden" Namen Obst(Backcolor) zugewiesen.

Für den Computer stellt sich jedoch die Frage:

Was hat das Vorliegen/Nichtvorliegen eines Signals mit Äpfel und Birnen zu tun? Klare, eindeutige Antwort: Gar nichts!

Nachdem zumindest eine mögliche Ursache Deines Problems nun anhand dieses Beispiels hoffentlich klar geworden sein dürfte, nochmals eine rein fachliche Erläuterung.

Für Fallentscheidungen gibt es zum einen eine IF-Anweisung (IF Vergleich .... THEN Ausführung), zum anderen eine IF-Funktion (IF(Vergleich, Ausführung bei positivem Vergleichsergebnis, Ausführung bei negativem Vergleichsergebnis). Beide sind sich - oberflächlich betrachtet - sehr ähnlich, unterscheiden sich in bestimmten Punkten (Handling, Anwendungsbereiche) allerdings deutlich voneinander! Während die IF-Anweisung im Wesentlichen für den Vergleich von Einzelwerten eingesetzt werden kann, ist es über die IF-Funktion möglich, nicht nur Einzelwerte sondern sogar ganze Arrays - also Datenreihen - miteinander zu vergleichen. Ich hatte diese Unterschiede bereits am 07. Februar diesen Jahres in einem Beitrag zum Thema "Fehlermeldung bei IF ... Then" unter der Rubrik "Programmierung und Schnittstellen" inklusive grafischer Darstellungen ausführlichst erläutert und möchte dies hier nicht noch einmal wiederholen. Der Kern ist in Bezug auf Deine Problemstellung auch ein klein wenig anders gelagert.

Du kannst also durchaus mit der von Dir in Deinem Code verwendeten IF-Funktion sehr wohl eine Fallunterscheidung für Einzelwerte durchführen - Du mußt allerdings dabei darauf achten, daß die sowohl für den Vergleich als auch für die aus dem Ergebnis des Vergleichs resultierenden Anweisungen verwendeten Datentypen gleich oder zumindest kompatibel - also miteinander verträglich sind - genau dies ist jedoch in Deiner Codezeile 3 nicht der Fall! Einen entsprechenden Hinweis findest Du sogar in dem Beipackzettel, den L&P seit der Version 7 zusammen mit dem Programm als großmäulig tituliertem "Referenzhandbuch" ausliefert.

In Deinem Codebeispiel vergleichst Du Boolean-Werte und forderst von dem Computer, daß er je nach Ausgang des Vergleichs einen bestimmten Farbwert zurückliefert. Nun läßt sich durchaus darüber diskutieren, von welchem Datentyp der entsprechende Farbwert ist bzw. sein könnte. Es ist jedoch davon auszugehen, daß er zu den Boolean-Werten des Vergleichs nicht kompatibel ist. Aus diesem Grunde ist der Computer auch mit Deiner Forderung etwas "überfordert", obwohl wir Menschen Deine Codezeile durchaus "verstehen" und darüberhinaus auch als völlig "plausibel" empfinden.

Die aus meinem Beitrag bisher resultierende "Message" für zukünftige, dauerhafte Problemvermeidung bei Fallunterscheidungen auf Basis von IF-Anweisungen bzw. IF-Funktionen lautet:

Wenn Du Arrays miteinander vergleichen willst, mußt Du praktischerweise die IF-Funktion an Stelle der IF-Anweisung verwenden. Willst Du jedoch eine Fallunterscheidung auf Basis einer Einzelwertprüfung durchführen, verwende besser eine IF-Anweisung an Stelle der IF-Funktion, weil Du Dir bei der Verwendung einer IF-Anweisung keine großen Gedanken über die Kompatibilität bzw. "Verträglichkeit" von Datentypen machen mußt! Zumindest schließt du von Vornherein bestimmte Fehlermöglichkeiten kategorisch aus!

An diesem Punkt meines Beitrags sind wir allerdings an dem Punkt angelangt, an dem ich noch zu knabbern habe. Als vermeintlich krönenden Abschluß habe ich Deinen Code-Dreizeiler einfach einmal als Spaltenformel in eine Liste kopiert und ausgestet (d.h. ich habe z.B. auch die Reihenfolge der Codezeilen von Ergebniswert und Ergebnisformatierung geändert!) Das Ergebnis war allerdings überraschend, denn ich konnte in allen Fällen eine völlig korrekte Farbgebung feststellen.

Das Ärgerliche daran ist nicht, daß die Sache bei mir funktioniert. Fakt ist und bleibt, daß Deine Codezeile 3 - streng formal gesehen - definitiv falsch sein müßte, da die verwendeten Datentypen meiner Meinung nach nicht korrekt sind. Fakt ist auch, daß viele Programmiersprachen insbesondere in puncto falsch deklarierte Datentypen (data type mismatch) extrem fehlertolerant sein können so daß bestimmte Sachen trotz eines vorliegenden formalen Fehlers einwandfrei funktionieren.
Das Ärgerliche ist, daß so langsam die Optionen für eine erfolgreiche Fehlersuche ausgehen.

Zur Zeit fallen mir eigentlich nur noch zwei Dinge ein.

1. Möglichkeit: Die Annahme ist nach wie vor: Der Fehler ist definitiv in Codezeile 3 zu finden! Hierzu meine konkrete Frage: Hast Du Deinen Code-Dreizeiler aus Deiner Spaltenformel in Deinen Beitrag kopiert oder abgeschrieben?

Der Grund für meine Frage ist folgender:

Beispiel 1:

3: Backcolor = if(Signal = True,Green,Red);

Beispiel 2:

3: Backcolor := if(Signal = True,Green,Red);

Sieht der Originalcode in Deiner Spaltenformel aus wie in Beispiel 1 oder wie in Beispiel 2? Entspricht Dein Code der Spaltenformel Beispiel 1, so hast du bei der Zuweisung des Rückgabewertes der IF-Funktion an Deine Variable Backcolor versehentlich statt des Zuweisungsoperators := ein Gleichheitszeichen verwendet. Codezeile 3 würde in diesem Fall nicht richtig funktionieren (keine Farbgebung!!!). Die Sache ist insofern tödlich, da - wenn ich mich recht erinnere - der ohnehin schon grottenschlechte Tai Pan-Formeleditor in diesem Falle bei der Codeprüfung auch keinerlei Fehlermeldung ausgibt; d.h. der Fehler bleibt dem Anwender zunächst verborgen.

2. Möglichkeit: Wenn Möglichkeit 1 als Fehlerursache nicht in Frage kommen sollte, bleibt meiner Meinung nach eigentlich nur noch die Möglichkeit übrig, das etwas mit (Deiner?) Tai Pan Version 14 nicht stimmt, denn sowohl Steffen als auch ich können Deinen Fehler offensichtlich nicht nachstellen und der einzig erkennbare Unterschied zwischen uns und Dir besteht darin, daß wir beide eben nicht Tai Pan 14 benutzen!

Vielleicht kann sich hierzu einmal ein anderer Tai Pan 14-User äußern. Ansonsten wäre es schön, wenn mal jemand von L&P vernünftig Laut von sich geben würde.

Der Ratschlag von Herrn Rohmann geht nämlich insofern am Thema vorbei und war auch in keiner Weise sonderlich hilfreich, da er auf eine IF-Anweisung einer ähnlich gelagerten Problematik irgendwo in den Tiefen von Tai Pan verweist, während bei Deinem Problem nicht irgendeine If-Anweisung, sondern eine formal eindeutig fehlerhafte Anwendung einer IF-Funktion vorliegt - er hat also versucht, Dir an Stelle Deines (madigen) Apfels eine vermeintlich herrliche Tai Pan-Birne anzudrehen. Solche "Luftnummern" als vermeintliche Hilfestellung bekommt man von L&P-Mitarbeitern bei der Hotline oder auch im Rahmen dieses Forums leider des öfteren "untergeschoben" - Herr Rohmann bildet da als "ausgewiesener L&P-Experte" für Tai Pan-Programmierung - die er meiner Meinung und vor allem meiner persönlichen Erfahrung nach auch zweifelsfrei ist - leider keine Ausnahme, obwohl er es - bezüglich der Unterschiede IF-Anweisung versus IF-Funktion - besser wissen müßte! Aber so ist es eben bei L&P und seinen Mitarbeitern: Man bekommt bei einer Vielzahl von Problemen generöserweise irgendwelche Brotkrumen vorgeworfen gemäß dem Prinzip friß oder stirb - echte, d.h. wirklich gute und vor allen Dingen brauchbare praxistaugliche Problemlösungen bzw. sinnvolle Erklärungen in Wort und Bild (Beispiel Handbuch) sind bei ernsthaften Problemen (von L&P) meist nicht zu erwarten - der Anwender muß sie sich, wie Dein Beispiel erneut zeigt, mühsamst selbst erarbeiten und darf mit etwas Glück auf die Unterstützung anderer, leidgeprüfter Tai Pan-Anwender im Rahmen dieses Forums hoffen.

Wäre also nett, wenn Du mir meine Frage zu Deiner Codezeile drei beantworten würdest - vielleicht ist damit das Problem dann endgültig geklärt.

Mit freundlichem Gruß

hound dog

Hallo Uwe,

das mit der grundsätzlichen Vorgehensweise ist eine alte Berufskrankheit. Ich habe jahrelang als IT Professional (Netzwerkadministration, Hotline, EDV-Schulung, nebenbei auch Scriptprogrammierung und Programmentwicklung) gearbeitet. Fehlersuche gehörte zu meinen täglichen Aufgaben. Wer bei der Fehlersuche in größeren Unternehmen aufgrund der Komplexität nicht grundsätzlich und zielgerichtet vorgeht, geht unter. Ansonsten bin ich ähnlich "gestrickt" wie Du. Auch wenn ich den Code von -zig Programmier- und Scriptsprachen lesen und verstehen kann, so bin ich doch kein (theoretisch exzellenter) Programmierer, sondern eher ein praxisorientierter Pragmatiker der sich zwar für elegante Lösungen begeistern kann, jedoch eher Wert darauf legt, daß überhaupt sinnvolle, praxisnahe Lösungen vorliegen bzw. geschaffen werden und vor allen Dingen auch fehlerfrei und reibungslos funktionieren. Genau dies ist bei Tai Pan bzw. bei L&P zumindest in den letzten sechs Jahren leider nicht (mehr) der Fall, weswegen der Programmierfähigkeit von Tai Pan sozusagen "in Eigenleistung" eine mit jedem Börsentag wachsende Bedeutung zukommt.

Im Übrigen - meinen absoluten Respekt. Du hast bei Deiner eigenen Fehlersuche verdammt tief gegraben. Ich verwende genau die gleiche Technik wie Du, d. h. ich schreibe (kleinere Formeln!!!) im Formeleditor und kopiere sie bei Bedarf in andere Formeln, das Listen- oder Filtermodul um. Bei etwas größeren Projekten führe ich Deinen Gedanken sinnvoll fort, schreibe den Code in einem externen, kostenlosen Programmeditor und kopiere am Schluß den fertigen Code zum Testen in den Formeleditor, da dieser, wenn man deutlich mehr als einen Codedreizeiler programmieren will, zu fehlerbehaftet und - in Bezug auf den Leistungsumfang - schlicht praxisuntauglich ist und somit eigentlich in die Abfalltonne gehört.

Beim Umkopieren des Codes vom Formeleditor ins Editorfenster des Listen- bzw. Filtermodul ist mir zwar auch schon aufgefallen, daß das Editorfenster irgendwie "anders" aussieht, auf die - aus meiner Sicht abartige - Idee, daß sich L&P bei dieser grundsätzlich grottenschlechten und dringendst verbesserungsbedürftigen "Programmierumgebung" den Luxus zweier Interpreter leistet, wäre ich nicht gekommen. Bei genauerer Betrachtung verwundert mich dies allerdings nicht: Bei L&P bzw. Tai Pan befindet sich der "Luxus" sehr häufig an unauffälligen Stellen, während an anderen, praxisrevanten Stellen "Großbaustellen" einen zügigen Arbeitsfluß dauerhaft be- bzw. verhindern.

Auf jeden Fall ist Deine empirisch erzielte Erkenntnis der unterschiedlichen Codeinterpretation der im Formeleditor, Listen- und Filtermodul hinterlegten Interpreter für mich eine extrem wichtige, neue Information, welche es bei der Entwicklung eigener Formeln unbedingt zu berücksichtigen gilt.

Informationen wie diese sind das Salz in der Suppe dieses Forums.

Vielen Dank dafür!

hound dog

Hallo liebe Kunden,

wir haben uns die beschriebene Problematik einmal angeschaut.
Wenn wir die Vorgehensweise richtig verstehen, wird im Formeleditor des Chartmoduls einen Formel erstellt.
Diese Formel enthält neben einem Ausgabewert in Form einer Zeitreihe, einen Ausgabewert mit einer Bedingung zu einer farblichen Gestaltung.
Diese Formel wird im Listenmodul über die Spalte "Indikator" hinzugefügt.
Das Listenmodul gibt den gewünschten Wert der Zeitreihe aus, aber nicht den zweiten Ausgabewert mit der farblichen Gestaltung anhand der programmierten Bedingung.
Ich hoffe wir haben soweit die Vorgehensweise und das gewünschte Ergebnis korrekt verstanden.

Es wurde ja gemutmaßt das zwischen Chartmodul und Listenmodul unterschiedliche Interpreter zum Einsatz kommen und dadurch nicht das gewünschte Ergebnis erzielt wird.
Dieses ist nicht korrekt. Der Formelinterpreter der Module ist identisch, jedoch stehen hinsichtlich der Ausgabe im Chartmodul und Listenmodul unterschiedliche Optionen zur Verfügung, wodurch die Module auch verschiedene Ergebnisse seitens der Formeln erwarten.

Das Problem bei der beschriebenen Vorgehensweise ist jedoch ein anderes. Die Listenspalte "Indikator" erwartet von der hinterlegten Formel lediglich als Ausgabe eine Zeitreihe. Andere Ergebnisse wie eine programmierte Farbgebung, werden von der Listenspalte "Indikator" nicht berücksichtigt und verarbeitet.
Die Ausgabe anderer Ergebnisse als eine Zeitreihe sind bisher für die Spalte "Indikator" bewusst von unserer Seite ausgeschaltet gewesen.
Es wird bei der Indikatorspalte erwartet, das der User eine Farbgebung oder ähnliches im dafür vorgesehenen Ausgabeeinstellungsdialog einstellt.
Anders als die Listenspalte "Indikator" reagiert die Listenspalte "Formel". Diese interpretiert auch andere Ausgabewerte als Zeitreihen, wie z.b. eine Farbgebung, etc.

Aus diesem Thread entnehmen wir, das unsere Kunden auch von einer Spalte "Indikator" ein anders Verhalten bzgl. der Ausgabe erwarten. Wir werden uns dieses einmal genauer anschauen und ggf. eine Änderung vornehmen, dahingehend das die Ausgabe einer Farbgebung auch mit der Listenspalte "Indikator" ermöglicht wird.

Grüsse aus Dortmund
Marcus Lieck

---

Leiter Produktsupport | Lenz+Partner GmbH | vwd group
Phone: +49 231 9153-500 | Fax: +49 231 9153-599
hotline@lp-software.de | www.LP-software.de | www.vwd.com

Guten Morgen Herr Michalowski,

die Unterschiede entstehen durch die Anwendung von Formel in verschiedenen Modulen.
An eine Formel die z.B. als Indikator im Chartmodul verwendet wird, stellt Tai-Pan andere Anforderungen als z.B. an eine Formel im Filtermodul.
Eine Filterformel benötigt einen Bedingung ja/nein bzw. 1/0 als Ausgabe, während eine Ausgabe ja/nein im Chartmodul als Indikatorformel keinen Sinn macht.

Der Grund für die Abschaltung, die übrigens im Listenmodul enthalten ist seit es die Spalte "Indikator" gibt ( Tai Pan 6), besteht in dem ursprünglich vom Entwickler erstellten Anwendungskonzept.
Die Spalte heisst "Indikator", dadurch erwartet das Programm eine Indikator-Zeitreihe aus der ein per Einstellungsdialog ausgewählter Wert ausgegeben wird.
Die Spalte ist ursprünglich nicht dazu da eine Auswertung/Bewertung einer Zeitreihe innerhalb der Indikatorformel auszugeben bzw. zu verarbeiten.Alles was über die Ausgabe des Indikatorwertes hinausgeht sollte der Kunde mit der Spalte "Formel" realisieren.
So war die Anwendung im Listenmodul ursprünglich konzipiert.

Wir werden versuchen dieses mit einem Programmupdate für Tai-Pan 14 zu ändern.

Grüsse aus Dortmund
Marcus Lieck

---

Leiter Produktsupport | Lenz+Partner GmbH | vwd group
Phone: +49 231 9153-500 | Fax: +49 231 9153-599
hotline@lp-software.de | www.LP-software.de | www.vwd.com

Hallo Herr Michalowski,

senden Sie mir doch bitte einmal ausführlich per Email Ihre genauen Anforderungen an die Listenverarbeitung.
Ich werde dann schauen welche Dinge wir ggf. in einem Tai-Pan 15 umsetzen können.

Grüsse aus Dortmund
Marcus Lieck

---

Leiter Produktsupport | Lenz+Partner GmbH | vwd group
Phone: +49 231 9153-500 | Fax: +49 231 9153-599
hotline@lp-software.de | www.LP-software.de | www.vwd.com