Wie Clipper 5 kompatibel ist xBase++

Auf dem Weg von Clipper, FoxPro u.ä. nach Xbase++

Moderator: Moderatoren

Antworten
HaglMi
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 30
Registriert: Mo, 27. Mär 2006 19:00
Wohnort: 84072 Au-Hallertau

Wie Clipper 5 kompatibel ist xBase++

Beitrag von HaglMi »

Hallo,

eine Frage an alle xbase++ Kenner:

Wie Clipper-5 kompatibel ist xBase++ ?
Es geht darum, eine umfangreiche Warenwirtschaft (diverse Zusatzlibs, teilweise stark modifiziertes Get-System, auch ADS) ev. auf xBase++ zu migrieren.
Es geht nicht darum, GUI-Elemente zu verwenden. Das ich die Zusatzlibs nachprogrammien muß ist schon klar. Das ganze sollte halt mit relativ geringem Aufwand erledingt sein. Das Programm habe ich Anfang des Jahres nach xHarbour umgesetzt, aber diverse Gründe/Wiedrigkeiten/Umstände lassen mich ernsthaft darüber nachdenken, die ganze Umstellungsorgie nochmal durch zu ziehen.
Ist das xbase++ Hauptfenster ein WinConsolenfenster oder ein echtes Windowsfenster, wo man zB. die Schriftgröße oder die Fenstergröße nach belieben einstellen kann ?

Vielen Dank im voraus

Michael Hagl
mfg Michael
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Wie Clipper 5 kompatibel ist xBase++

Beitrag von AUGE_OHR »

HaglMi hat geschrieben:Wie Clipper-5 kompatibel ist xBase++ ?
99,99%
HaglMi hat geschrieben:Das Programm habe ich Anfang des Jahres nach xHarbour umgesetzt, aber diverse Gründe/Wiedrigkeiten/Umstände lassen mich ernsthaft darüber nachdenken, die ganze Umstellungsorgie nochmal durch zu ziehen.
WARUM ??? Wenn du auf Xbase++ "zurück-gehst" wird die Geschwindigkeit um Faktor 10 "abnehmen" !!!

Ich habe diverse Xbase++ activeX Module auf harbour umgestellt weil der Geschwindigkeit Unterschied bei activeX extrem ist.
Bis zu Faktor 40 (!!!) läuft der selbe Source nun schneller.

Frage : warum nicht GUI ? bei Hybrid kannst du auch gleich bei Cl*pper bleiben (schneller)

überhaupt frage ich mich welche Contribution benutzt du ? für GUI gibt es von Bedi Pritpal die GTWVG welche zu 98% Xbase++ GUI compatibel ist.

Der einzige Grund von harbour auf Xbase++ "zurück-zu-gehen" wäre Express++ weil du dort schnell deine Cl*pper SAY/GET nach Xbase++ GUI umsetzten könntest.

btw. ich sehe gerade xharbour :(
ich rede "nur" von harbour (free), den "nur" dafür gibt es die "freien" Constributionen
gruss by OHR
Jimmy
HaglMi
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 30
Registriert: Mo, 27. Mär 2006 19:00
Wohnort: 84072 Au-Hallertau

Re: Wie Clipper 5 kompatibel ist xBase++

Beitrag von HaglMi »

Ist xBase++ tatsächlich so langsam ? Was ist da langsam, die Oberfläche CRT- oder Hybridmodus, oder die grundsätzliche Programmausführung. Gibt es ein Programm, daß man irgendow runterladen kann, um einen Eindruck davon zu bekommen (Hybridmodus) ?

Auf GUI umstellen, bedeutet für mich neu schreiben und das mache ich bestimmt nicht in dem beknackten Eventmodell von Win32. Da ist DotNet schon wesentlich handsamer.
Bei Clipper kann man nicht bleiben, wegen Win7, ActiveX, Officeanbindung usw. Mittlerweile ist mein Programm so umfangreich, daß Clipper 5.2 an seine Compilergrenzen gestossen ist. Clipper 5.3 ging wegen zu wenig DOS-Speicher gar nicht mehr (zu viel Präprozessor).

Ich benutze den kostenpflichtigen xHarbour Builder. Es insteressiert mich eigentlich nicht, ob eine Entwicklungsumgebung Geld kostet, hautsache Sie funktioniert und es muß sich jemand darum kümmern, wenn Fehler auftauchen. Und das ist bei xHarbour durchaus ein Problem. Keiner ist für irgenwas zuständig, oder gar verantwortlich. Die gilt besonders für den ADSRDD, aber auch für GTWVT, GTWVW und GTWVG. Dokumentiert ist eigentlich so gut wie gar nichts. Ich kann den Spruch vom zugänglichen Quellcode einfach nicht mehr höhren. Wenn ich C-Programmierer werden wollte, würde ich bestimmt nicht in xHarbour programmieren.

Visual xHarbour zB gebe ich keine Zukunft. Die IDE liegt Lichtjahre hinter VO und von den Möglichkeiten, die die VIDE für Vulcan oder auch VisualStudio bieten braucht man gar nicht zu reden (Intellisence erhöht die Codiergeschwindigkeit dramatisch), aber das ist hier nicht das Thema.

Ich möchte einfach nur mal ausloten, ob es mit xBase++ weniger Probleme gibt. Ich gehe mal davon aus, daß zB. der ADS-Client hier funktioniert. Bei xHarbour gibt es offensichtlich so wenig Anwendungen mit ADS, das diese von Sybase gar nicht wahrgenommen werden. Langsam habe ich das Gefühl, daß es einfach keine richtig großen Anwendungen mit xHarbour gibt.

Ich denke, ich werde bis ende des Jahres einige Tage investieren und schauen wie sich eine Umsetzung nach xBase++ anfühlt, bzw. ob es wirklich so langsam ist.

Michael Hagl
mfg Michael
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Wie Clipper 5 kompatibel ist xBase++

Beitrag von brandelh »

Hallo,

für die Devcon habe ich damals eine Beispielanwendung von Clipper 5.0 nach Xbase++ umgesetzt.
Diese verwendet z.B. auch die Anpassung der Bildschirmschrift für das XbpCRT() Programm.
Dieses Beispiel wurde von einem umfangreichen Clipper 5.0 Programm herausgelöst, das ich
vor Jahren auf Xbase++ umgestellt habe (mit clipper Optik) und die Anwender benutzen es jetzt
seit vielen Jahren (ab 1989 Clipper ..., Xbase++ weiß ich jetzt nicht).
Den Aufwand für die Bibliotheken kann ich nicht abschätzen, bei dem Get-System gibt es ab und
zu kleine Inkompatibilitäten, die ich damals aber locker ausbügeln konnte. DAS ging wirklich schnell !
Array Elemente im GET System z.B. werden direkt angesprochen (was ein Vorteil ist) und deshalb
wurde eine Systemvariable nicht gesetzt, die den Array-Index unter Clipper speichert.
Da musste ich halt diesen jeweils beim Aufbau setzen, das ging - ich meine ich hätte es hier auch
damals irgendwo beschrieben.

Wenn man beim GUI=NO einstellt, ist es ein Consolenprogramm, ohne weitergehende Möglichkeiten.
Dies ist aber heute nicht mehr zu empfehlen, GUI=YES (= XbpCRT() wird genutzt) sieht zwar fast
gleich aus, kann aber fonts ändern, drucken mit XbpPrinter (besser HBPrinter ;-) ) etc.

Ich kann nicht beurteilen, wie schnell die harbour -> C Programme sind, aber wirklich sehr langsam ist
Xbase++ nur bei ActiveX Einzelzellen Manipulation. Wenn man das aber z.B. über Arrays regelt geht das
auch schnell. Natürlich sind Xbase++ Programme z.B. in for next Schleifen langsamer als z.B. PowerBasic
aber das spielt nicht wirklich eine Rolle.

Auf CLIPPER bleiben halte ich persönlich für höchst gefährlich !
Die Zeit ist reif für 64 Bit Betriebssysteme (ich habe gerade auf Win7 64bit umgestellt) und dort
läuft definitiv KEIN DOS Programm mehr (eventuell in ultimate mit XP unterstützung ?) und man muss
einfach damit rechnen, dass Kunden die neuen System einsetzen !

Und zu guter Letzt, sind hier einige die damit viel Erfahrung haben und sich gerne die Finger wund schreiben
wenn man Hilfe braucht ;-)
Gruß
Hubert
Benutzeravatar
Lewi
1000 working lines a day
1000 working lines a day
Beiträge: 830
Registriert: Di, 07. Feb 2006 14:10
Wohnort: Hamburg
Danksagung erhalten: 2 Mal

Re: Wie Clipper 5 kompatibel ist xBase++

Beitrag von Lewi »

Hallo Hagle,
der von Jimmy angesprochene Geschwindigkeitsvorteil von xHabour gegenüber xBase mag zwar im Zusammenhang mit activeX stimmen, aber im Zusammenhang mit WaWi`s ist für mich dieser Aspekt in keiner Weise relevant.

Für ein WaWi erachte ich Dinge wie Benutzerfreundlichkeit, schnelles Eingabe-Interface, schnelle und sichere Datenbankoperationen sowie Auswertungen und Listen als Maßgebend. Aus der Sicht eines Entwicklers kommt dann noch deren Umsetzbarkeit und die Stabilität der entwickelten Anwednung hinzu.

All diese Anforderungen lassen sich mit xBase++ realisieren. Abseits der von Active-Anbindungen sind Geschwindigkeits-Diskussionen auf Basis der heutigen PC-Performance rein akademischer Natur. Letztendlich sind WaWi´s Datenbank-Applikationen. Und in diesem Zusammenhang müssen Performance-Betrachtungen unter dem Gesichtpunkt einer jeweiligen IT-Struktur, deren Hardware und der Datenbank (ADS versus DBF) gesehen werden.

Wenn Du zudem (ausschließlich) in der xBase-Welt zu Hause bist, bleibt meines Erachtens ohnehin nur eine Alternative: xBase++ und ADS. Für die Portierung gibt es eine Reihe wirklich guter Add-Ons (Express, xClass, L&L, FRAX, SQL-Express etc.) mit denen nahezu jede Anforderung mit xBase++ umgesetzt werden kann.

Viele Grüße
Olaf
Benutzeravatar
Markus Walter
Programmier-Gott
Programmier-Gott
Beiträge: 1018
Registriert: Di, 24. Jan 2006 10:22
Wohnort: Saarland

Re: Wie Clipper 5 kompatibel ist xBase++

Beitrag von Markus Walter »

Hallo,

auch ich möchte meinen Senf dazugeben:

Dieser Geschwindigkeitsfaktor 10, den Jimmy nennt, mag es im Zusammenhang mit ActiveX geben. Das kann ich nicht beurteilen. Deswegen die Portierung nicht zu machen, ist aber absoluter Quatsch. Ich selbst habe ein umfangreiches WaWi von Clipper nach Xbase portiert und habe heute einen Misch aus "alten" Crt-Fenstern und vielen, vielen Gui-Fenstern. Ich nutze auch ActiveX (z. B. das TxTextControl). Mit der Geschwindigkeit habe ich nicht wirklich Probleme. Die Aussagen von Jimmy halte ich da für ziemlich akademisch :) (oh weh, jetzt wird er über mich herfallen... :wink: ). Das eine ist ActiveX, mag sein, dass es bei massenhaft ActiveX-Aufrufen da merkliche Unterschiede gibt, keine Ahnung.

Das andere Lieblingsthema von Jimmy ist die "2-D-Grafik" von Xbase. Hier kommen immer Beispiele, dass CodeJock auf einem alten Rechner viel schneller zeichnet, als die Xbase-Parts (z. B. bei hundert Pushbuttons in einer Form). Auch das wird in einem "normalen" Umfeld kein Thema sein.

Crt/Hybrid ist definitiv langsamer als Clipper. Aber wenn man nicht bei Clipper bleiben kann, ist das kein Todschlag-Argument. Bei mir mussten rund 1500 Anwender von Clipper zu Xbase/Hybrid wechseln und es gab kein Gemaule...

Also die Entscheidung, ob Xbase++ oder nicht, muss man auf anderer Ebene treffen. Ob habour/xHarbour da eine Alternative ist, muss auch jeder für sich selbst beantworten. Für mich wäre es keine.
Gruß
Markus

Mitglied der XUG Saarland-Pfalz
Benutzeravatar
Rolf Ramacher
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1930
Registriert: Do, 09. Nov 2006 10:33
Wohnort: Bergheim
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Wie Clipper 5 kompatibel ist xBase++

Beitrag von Rolf Ramacher »

Hallo Hagle,

bezgl. xHarbour solltest du mal - "Herbert" kontaktieren. Der hatte hiermit schon mal was getan. War aber überhaupt nicht begeistert und hat das ganze wieder eingestampft. Ich bin dabei mein Wawi auf Xbase GUI umzuprogrammieren. Ist zwar viel arbeit aber macht m.E am meisten Sinn, anstatt erst auf CRT-Fenster und später doch auf GUI umzumodeln. Denn auf CRT-Fenster kannst du auch nicht ewig stehen bleiben.

Zumal du hierbei auch die Möglichkeit hast, dich von alten Zöpfen zu lösen. Denn das war bei mir der entscheidénde Punkt.
Gruß Rolf

Mitglied der Gruppe XUG-Cologne
www.xug-cologne.de
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Wie Clipper 5 kompatibel ist xBase++

Beitrag von AUGE_OHR »

hi,

vorweg : I LOVE Xbase++ !!!

beim Eingangs Posting ging es doch darum ein in harbour lauffähiges Programm nach Xbase++ umzusetzen.
Dies ist mit der GTWVG Constribution von Bedi Pritpal und meiner Hbxbase.CH sofort (!!!) zu 98%, incl. GUI, möglich.

was die Geschwindigkeit angeht scheint es mir das euch nicht allen klar ist was harbour macht ?
harbour erzeugt NICHT die Application sondern ist eine Art Pre-Prozessor der "reinen" C Code erzeugt !

Als Compiler / Linker kann man dann alle möglichen C Compiler verwenden und sogar für Linux soll es was geben ( Ming ?)
Somit ist wohl klar das eine reine C Anwendung schneller ist als Xbase++ ... von .NET gar nicht zu reden.

btw. wenn man "reinen" Code hat sollte es doch "kein Problem" nach .NET sein ... oder ?

Ich gebe euch aber Recht wenn ihr sagt, das es in einem "normalen" Programm keine grosse Rolle spielt ob es 0.1sec oder 0.4sec sind.
Daran gewöhnt sich der User schon so wie bei Cl*pper -> Xbase++ ... und es gibt ja auch die Möglichkeit bei der Hardware nachzurüsten.

Nur bei Reports, Import, Export oder so ist es schon nett wenn das statt 40min nur noch 1min dauert ;)
Für solche Zwecke nutze ich jetzt öfter harbour und lasse es per Runshell laufen.

Dazu pflege ich meinen Source Code nun "Dual fähig" zu schreiben d.h. ich verwenden nicht nur Xbase++ sondern es erfolgt eine "Gegenkontrolle" per harbour.

Ich behaupte ja immer das Software nie fertig ist, es gibt immer BUGs, aber sie wird nicht besser wenn "man" sich nicht darum kümmert.
Wenn nun viele sich darum kümmern wird auch der Entwickler nicht umhin kommen was zu unternehmen, aber dazu ist jeder einzelne gefordert.

harbour ist ja Open Source, xHarbour die "kommerzielle" Version mit Support so ähnlich wie bei Xbase++ ...
Wenn man also ein "Problem" hat wendet man ich bei den "kommerziellen" an den Support der aus "einigen" Leuten besteht.
Hat man nun ein harbour "Problem" geht man in die Newsforen an "viele" Leute und versucht dort die Antwort zu finden oder wendet sich an den Entwicker selbst.

Ich stehe nun mit Bedi Pritpal, dem Entwickler der GTWVG, seit 1 Jahr ständig in Verbindung. Sobald ich ein Hbxbase "Problem" finde mache ich ein Demo und schicke es ihm damit wir auf 99% kommen ... und irgendwann auf 99,99%

Mit dem "dual fähigen" Code halte ich mir also alles Möglichkeiten offen "wenn" es Xbase++ nicht klappt, wie beim Codejock Calendar, das ich nicht auf eine "Fix" vom Support warten muss.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Wie Clipper 5 kompatibel ist xBase++

Beitrag von AUGE_OHR »

brandelh hat geschrieben:Auf CLIPPER bleiben halte ich persönlich für höchst gefährlich !
YUP
brandelh hat geschrieben:Die Zeit ist reif für 64 Bit Betriebssysteme (ich habe gerade auf Win7 64bit umgestellt) und dort
läuft definitiv KEIN DOS Programm mehr (eventuell in ultimate mit XP unterstützung ?) und man muss
einfach damit rechnen, dass Kunden die neuen System einsetzen !
hm ... aber ich habe schon mein Cl*pper Programm auf eine XP64 laufen lassen ... unter Win7x64 hab ich es noch nicht getestet.
Kann sein das ich da eine "Kompatibilitäts-Modus" benutzt habe ... aber irgendwie ging es dann.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Wie Clipper 5 kompatibel ist xBase++

Beitrag von AUGE_OHR »

Markus Walter hat geschrieben:Also die Entscheidung, ob Xbase++ oder nicht, muss man auf anderer Ebene treffen. Ob habour/xHarbour da eine Alternative ist, muss auch jeder für sich selbst beantworten. Für mich wäre es keine.
Es könnte aber doch eine sein wenn du nur eine Hbxbase.CH einbinden müsst ?

und genau das ist ja der "Trick" an der GTWVG Constribution von Bedi Pritpal. Er ist auch der Entwickler von Vouch32 der Cl*pper mit der Windows Welt verbindet.

Bedi hat selbst früher in Xbase++ programmiert und ist schon vor Jahren an die Grenzen von Xbase++ gestossen.
Wie ich mag er aber den Classy Style und hat diesen in die Entwicklung der GTWVG implementiert wobei er sich an das Xbase++ "Vorbild" gehalten hat.

Meine Aufgabe war es "lediglich" per #xTranslate Xbase++ auf GTWVG "um-zu-biegen"

Code: Alles auswählen

   #xtranslate XbpDialog                       =>  WvgDialog
   #xtranslate XbpStatusBar                    =>  WvgStatusBar
   #xtranslate XbpStatic                       =>  WvgStatic
   #xtranslate XbpActiveXControl               =>  WvgActiveXControl
   #xtranslate XbpPushButton                   =>  WvgPushButton
   #xtranslate XbpComboBox                     =>  WvgComboBox
   #xtranslate XbpTreeView                     =>  WvgTreeView
   #xtranslate XbpMenu                         =>  WvgMenu
   #xtranslate XbpToolBar                      =>  WvgToolBar
   #xtranslate XbpMenuBar                      =>  WvgMenuBar
   #xtranslate XbpListbox                      =>  WvgListbox
   #xtranslate XbpMLE                          =>  WvgMLE
...
sodas man nur die HbxBase.CH einbinden muss und nichts weiter !!!

Man schreibt also wie gewohnt seinen Xbase++ Code, nur das er dann eben "Gegen kontrolliert" wird mittels harbour um ggf. "Kleinigkeiten" anzupassen (98% OK)

Ob man damit auch bei "grossen" Projekt klarkommt versuche ich gerade raus zu bekommen, den meine neuste Creation verwendet all die schicken (langsamen) activeX
Codejock Tools wie Ribbonbar, ShortCutBar, Calendar, Datepicker und überall Icons ... und Animationen nach Win7 Style ...
Cal_Entry.JPG
Cal_Entry.JPG (123.03 KiB) 10656 mal betrachtet
Allerdings hat es auch einen Grund das ich den Source Code "Dual fähig" schreiben muss, denn wie ich auch beim Usertreffen gezeigt habe gibt es leider Situationen wo Xbase++ "versagt" :(

Es liegt nun wohl an Xbase++ (up to v1.9.355) da eben der selbe Source in der "Gegen Kontrolle" mit harbour funktioniert =D> ... oder was würdet ihr in einer solchen Situation vermuten ?

Wenn Alaska es also bis Ende des Jahre nicht schafft diese Problem zu beheben, MUSS ich die Application in harbour statt Xbase++ ausliefern...
gruss by OHR
Jimmy
HaglMi
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 30
Registriert: Mo, 27. Mär 2006 19:00
Wohnort: 84072 Au-Hallertau

Re: Wie Clipper 5 kompatibel ist xBase++

Beitrag von HaglMi »

Hallo,

vielen Dank für die vielen Antworten.
Es liegt mir in jedem Fall fern, wieder einen Glaubenskrieg anzufachen. MIr geht es einzig und alleine darum, auszuloten, ob in meiner jetzigen Situation (Programm läuft mit xHarbour, Pagescript, ADS, ein wenig OLE mit Word und Excel) xBase++ eine bessere Wahl wäre. Denn der Support für xHarbour ist, wenn man es genau nimmt sehr bescheiden, wenn es um eingemachte Probleme (wie zB den ADSRDD) geht. Da hilft nur warten, hoffen und bohren, daß sich einer der Entwickler ev. vielleicht dem Problem annimmt oder es versuchen selbst zu lösen, aber da muß man in die Untiefen von C runter und damit ist es auch noch nicht getan.

@Jimmy
Auch der beste C-Code hilft Dir bei Dotnet nichts. Dotnet ist eine völlig andere Welt der Softwareentwicklung mit einem völlig anderen Eventsystem.

Ich möchte ehrlicherweise auch sagen, daß selbst wenn ich nach xBase++ portiere, dort sicher nicht meine Zukunft liegt. Das selbe gilt auch für xHarbour. Denn ein echter Umstieg auf GUI ist im Grunde immer mit neu schreiben verbunden. Und neu schreiben dauert halt einige Zeit, deshalb der momentane Wechsel von Clipper nach xHarbour bzw. ev. xBase++. Aber beim neu schreiben hätte ich gerne eine funktionierende und gute IDE, ein durchdachtes Eventsystem und eine umfangreiche Programmbibliothek, wo ich davon ausgehen kann, daß die bereits von 1 Mio Programmierern verwendet und getestet ist. Und für mich bedeutet das eben Dotnet, wobei es hier im Grunde egal ist, ob man C#, Vulcan oder sonst was verwendet. Man kann ja problemlos mischen. Als xbase-Programmierer fühle ich mich in Vulcan natürlich wesentlich wohler und gegenüber den anderen Dotnet-Sprachen hat deshalb Vulcan schon einige Vorteile: eingebaute DBF-Unterstützung, (ich weiß, daß der Trend auch bei Popelanwendungen zu SQL geht), sehr umfangreiche Macrocompiler (wer von euch möchte darauf verzichten), natürlich geht hier auch das allseits bekannte dbUseArea(..).
Vulcan nur als Nachfolgeprodukt für VO zu bezeichen, wird der Sprache aber nicht gerecht. Ich glaube jetzt auch nicht, daß an xBase++ mehr Entwickler arbeiten als an Vulcan. Da sitzen wir alle im Glashaus. Hier müsste die theoretische Konsequenz für uns alle beudeten: hin zu C++, VB, C#, Delphi (na ja), Java usw.

Michael Hagl
mfg Michael
Antworten