Verbesserungsvorschläge für Express++ ?

[AUGE_OHR]

hi,
ich hab nun den Express++ v250 Source "fast" durch und frage mich ob es von Interesse ist
darüber zu sprechen ? Mir ist inzwischen "bewusst" das ein Express++ User gar nicht unbedingt
daran interessiert ist wie der Source aussieht ... aber man könnte ihn ja "optimieren" !

Beispiel : C:\EXP19\Source\Dclipx\_dcxbutt.prg das ist die ButtonXP Class

Code: Alles auswählen

METHOD DC_XbpPushButtonXP:Draw()
...
   FOR i := nStart TO nEnd STEP nStep

kein Wunder das die ButtonXP "so langsam" sind wenn man in der Draw() Methode eine FOR/NEXT
hat.

[brandelh]

... aber man könnte ihn ja "optimieren" !

spätestens beim nächsten Update wird man es büßen

Code: Alles auswählen

METHOD DC_XbpPushButtonXP:Draw()
...
FOR i := nStart TO nEnd STEP nStep

kein Wunder das die ButtonXP "so langsam" sind wenn man in der Draw() Methode eine FOR/NEXT hat.

Ab und zu kommt man halt nicht drum herum ...
wäre halt schön wenn man wenigsten mit LONG Integer arbeiten könnte aber das hatten wir ja schon

[FlashNash]

hi,
Mir ist inzwischen "bewusst" das ein Express++ User gar nicht unbedingt
daran interessiert ist wie der Source aussieht ...

Da liegt Du falsch Jimmy.... MICH persönlich interessiert das sehr wohl. Jedoch hätte ich zunächst mal lieber eine funzende Express Version unter der ich meine alten Clipper-Sourcen i.V. mit der aktuellen XBase v1.9 Build 331 compillieren könnte um zu sehen, was genau macht das DING (express) daraus. Ist, so glaube ich, für 299,- Dollores keine unverschämte Forderung ....

Was genau soll ich alleine mit dem Express Sourcecode anstellen, wenn die Dinge (älteren Clipper Source), die ich damit megrieren möchte, nicht ablauf/runnmäßig einsehbar sind???

[AUGE_OHR]

hi,

Mir ist inzwischen "bewusst" das ein Express++ User gar nicht unbedingt
daran interessiert ist wie der Source aussieht ...

das ergab sich so aus einer Umfrage im Express++ Forum

Was genau soll ich alleine mit dem Express Sourcecode anstellen, wenn die Dinge (älteren Clipper Source), die ich damit megrieren möchte, nicht ablauf/runnmäßig einsehbar sind???

Frage an Express++ User : wie debugge ich den Express++ "Kernel" Source Code ?

daran siehst du das es nicht das ist was du denkt. Express++ ist eine Command Sprache
d.h. du "siehst" von Xbase++ nichts sondern verwendest die *.CH für die #Translate.
Wie man allerdings eine *.CH debuggen kann ... (wie debugge ich eine DLL / LIB )

Parameter gibt es dann bei DC_Function als (geschriebene) Option was aber nichts über die
Reihenfolge aussagt ... das alles macht Express++

Im Grunde kann man sagen: man braucht keine Xbase++ Vorkenntnisse um mit Express++ zu
arbeiten ... oder andersrum wird ein Express++ User nicht über das Level von Express++ raus-
kommen ... und das will der normale Express++ scheinbar gar nicht.

Also wenn du so ähnlich wie ich "ganz tief" in die Materie eintauchen willst dann solltest du
dir auch mal YUKON oder Cockpit ansehen. Diese verfügen über "andere" Parts die die XbParts
ersetzten können aber leider bislang auch auf die "Common Controls" setzten. Ich denke aber
das eher von der Seite was kommen wird als von Alaska und somit Express++ / Topdown da
die beiden ja die XbParts als SuperClass verwenden.

und last but not least : es gibt das XCodeJock Project.
klar kosten die CodeJock activeX was, aber Roger liefert die CJ / DClipX als LIB dazu sodas man
kein Express++ benötigt ... und man hat eine Windows 7 Lösung.

[FlashNash]

Deine Ausführungen in Gottes Ohr Jimmy...

Yukon, Cockpit und CodeJock ist alles nichts unbekanntes, zumindest und teilweise vom ´einlesen´ her. Alles gut und schön, nur eine anständige Express Version muss her d.h. abflauf + compillierungsfähig mit der neuesten und aktuellen XBase Version 1.9 Build 331 ... damit alle alten und interessierte Clipper-Hasen, die ihre alten Clipper Sourcen damit ´vorerst oder für immer´ (wie auch immer) megrieren möchten, mal einen optischen/funktionellen real Eindruck bekommen, bevor sie 299 Dollar nach USA überweisen .... nicht mehr nicht weniger. Die Ansage ist doch bestimmt nicht ´vermessen/arrogant´.

Eine runnende Express Demoversion muss her, was ja auch Terminus des Threads hier ist: `Verbesserungsvorschläge für Express++ ´. Damit meine ich eine Demoversion, durch die jeder Programmierer sehen kann, was genau er für´s Geld (299,- Dollar) bekommt ... nicht mehr und nicht weniger. Nur darum geht es mir persönlich. Ich hoffe, Roger wird das recht schnell genau so sehen .... na schaun mer amol.

DAS ist mein Beitrag zum Thema: Verbesserungsvorschläge für Express++

[AUGE_OHR]

hi,

DAS ist mein Beitrag zum Thema: Verbesserungsvorschläge für Express++

Du hast völlig Recht.
Es ist jetzt über 1 Monat her als ich Roger auf die Demo aufmerksam machte das die nicht
funktioniert worauf er bei mir auch reagiert hat. Es ist "im Prinzip" ja auch nur eine Sache von
5min das ganze in der "aktuellen" Version zu erstellen ... nur genau da liegt "ein wenig" das
Problem ...

Wegen dem Project XCodeJock ist er "ständig" an die *.CH Dateien dran und mit jedem
XCodejock Schritt muss ich die *.CH, *.PRG in die "richtigen" Verzeichnisse kopieren und mir
eine aktuelle LIB und DLLs erstellen ... und es ändert sich z.Z. "ständig" ...

Vielleicht sollte man die letzte Code Version vor XCodeJock nehmen (Express++ v249?) ,
die müsste auch SL1 v350 fähig sein, und daraus eine Demo Version machen ?!

Frage an Sysop : wie sieht es mit Upload aus ?

[AUGE_OHR]

hi,

... aber man könnte ihn ja "optimieren" !

spätestens beim nächsten Update wird man es büßen ;-)

naja ich hatte es mir so gedacht, das wenn wir tatsächlich eine "optimierte" Version finden,
die dann natürlich Roger mailen und er sich das ansehen kann.

Code: Alles auswählen

METHOD DC_XbpPushButtonXP:Draw()
...
FOR i := nStart TO nEnd STEP nStep

kein Wunder das die ButtonXP "so langsam" sind wenn man in der Draw() Methode eine FOR/NEXT hat.

Ab und zu kommt man halt nicht drum herum ...

Ich bis mir da nicht sicher ... wenn ich eine FOR / NEXT in einer :Draw Methode sehe dann
denke ich das man sich sowas "genauer" ansehen sollte. Wenn am Bildschirm durch :Draw
etwas "ausgegeben" wird dann merkt das jeder User und wird fragen wieso das so langsam
passiert. 100 und mehr Pushbuttons ... das merkt auch ein DAU

Die FOR / NEXT in der :Draw() Methode viel mir nun gerade auf und ist nur ein Beispiel um
zu testen ob es ein Interesse gibt ... auch für nicht Express++ User.

[Martin Altmann]

Hallo Jimmy,
geht es denn schneller, wenn Du es mit dem :lockUpdate(.T./.F.)-Mechanismus probierst?

Viele Grüße,
Martin

[AUGE_OHR]

hi,

geht es denn schneller, wenn Du es mit dem :lockUpdate(.T./.F.)-Mechanismus probierst?

woher soll ich den das wissen ... ich benutzte doch gar kein Express++ ... ich "lese" doch nur.

Code: Alles auswählen

CLASS DC_XbpPushButtonXP FROM DC_XbpPushButtonXPSuper, DC_XbaseParts
METHOD Init, Create, Action, GetShortCut, SetShortCut, Destroy, ;
       WhenHideEval, Draw, SetFontName, LbClick, SetCaption, ;
METHOD DC_XbpPushButtonXP:Init( oParent, oOwner, aPos, aSize, aPres, lVisible,
::drawMode := XBP_DRAW_OWNER
METHOD DC_XbpPushButtonXP:create( oParent, oOwner, aPos, aSize, ;
METHOD DC_XbpPushButtonXP:Draw( oPS, mp2, nMode )
ELSEIF BAND(mp2[3],XBP_DRAWSTATE_SELECTED) != 0
ELSEIF BAND(mp2[3],XBP_DRAWSTATE_DISABLED) != 0
        oTileBitMap:draw( oPS, aTarget, aSource, GRA_BLT_BBO_IGNORE )
IF BAND(mp2[3],XBP_DRAWSTATE_DISABLED) != 0
ELSEIF BAND(mp2[3],XBP_DRAWSTATE_SELECTED) != 0
    oBitmap:draw( oPS, aTarget, aSource, ;
IF !::isStatic .AND. ::focusRectStyle > 0 .AND. BAND(mp2[3],XBP_DRAWSTATE_FOCU
RETURN ::XbpPushButton:Draw(oPS, mp2)

METHOD DC_XbpPushButtonXP:MouseEnter()
METHOD DC_XbpPushButtonXP:MouseLeave()
METHOD DC_XbpPushButtonXP:lbClick( aPos )
METHOD DC_XbpPushButtonXP:WhenHideEval( lEnable, lShow, lProtect, nMode )
METHOD DC_XbpPushButtonXP:SetShortCut()
METHOD DC_XbpPushButtonXP:destroy()
METHOD DC_XbpPushButtonXP:GetShortCut()
METHOD DC_XbpPushButtonXP:Action( a, b, o )
METHOD DC_XbpPushButtonXP:SetFontName( cFont )
METHOD DC_XbpPushButtonXP:SetFontNameMouseOver( cFont )
METHOD DC_XbpPushButtonXP:SetBitMap( oBitMap )
METHOD DC_XbpPushButtonXP:SetBitMapTile( oBitMap )
METHOD DC_XbpPushButtonXP:SetCaptionStr( cCaption )
METHOD DC_XbpPushButtonXP:SetCaption( cCaption )
METHOD DC_XbpPushButtonXP:SetCaptionArray( aCaption )
METHOD DC_XbpPushButtonXP:RefreshCaptionArray()
METHOD DC_XbpPushButtonXP:ConfigureCaptionArray( lInvalidate )

das sagt mir nun mein Editor. Ein :lockUpdate(.T./.F.) wird in der DC_XbpPushButtonXP Class
selbst nicht benutzt, aber es wird wohl "vorher" schon gesetzt sein , den es handelt sich ja
wohl um Ownerdraw. Man müsste sich mal das Demo dazu vornehmen und sehen wie ein
Codeblock für den Ownerdraw Aufruf aussieht.

weiss vielleicht ein Express++ User darüber Bescheid ?

[Martin Altmann]

Jimmy,
mir ging es bei meiner Frage nicht unbedingt um eXpress++
Du hast DIch doch beschwert, dass unter Window 7 das Zeichnen der Xbase-Parts so lange dauert!! Pascal Bovin hat Dir doch in der SL1-group geantwortet
Mich würde jetzt nur mal interessieren, ob es damit bei Dir schneller geht - hat überhaupt nix nur mit eXpress++ zu tun. Ich stelle die Frage ja auch nur deshalb hier, weil Du Dich hier auf Geschwindigkeit und auch auf Windows 7 bezogen hast...

Viele Grüße,
Martin

[AUGE_OHR]

hi,

mir ging es bei meiner Frage nicht unbedingt um eXpress++

aber der Thread hier heist doch: Verbesserungsvorschläge für Express++

Du hast DIch doch beschwert, dass unter Window 7 das Zeichnen der Xbase-Parts so lange dauert!! Pascal Bovin hat Dir doch in der SL1-group geantwortet
Mich würde jetzt nur mal interessieren, ob es damit bei Dir schneller geht - hat überhaupt nix nur mit eXpress++ zu tun. Ich stelle die Frage ja auch nur deshalb hier, weil Du Dich hier auf Geschwindigkeit und auch auf Windows 7 bezogen hast...

ah so das meintest du, das muss ich noch evaluieren.

[Manfred]

Hi Jimmy,

ich habe nicht soviel Grundwissen, aber auf jeden Fall Interesse an der funktionsweise von express++. Deshalb habe ich den gesamten Code auch mit Debugger Informationen versehen und schaue mir wenn, ALLES im Debugger an. So sehe ich natürlich auch, wie express++ funktioniert. Ob das jetzt ausreicht, weiß ich nicht, aber es ist zumindest ein Anfang.
Wie an meinen bisherigen Fragen hier zu erkennen sein sollte, lege ich auch Wert darauf Schleifen usw. gegen schnellere Alternativen zu ersetzen, wenn es irgendwie möglich ist. Leider steht mir aber im Moment der Kopf woanders und deshalb kann ich auch nur das sehen, was ich halt gerade durch einen gezielten Durchlauf erkennen kann. Tiefgreifend, so wie Du, kann/könnte ich im Moment eh nicht vorgehen. Aus mehreren Gründen schon nicht. Dazu habe ich z.B. einfach nicht das nötige Fachwissen. Aber ich arbeite täglich daran.

[Tom]

Hallo, Jimmy.

Im Grunde kann man sagen: man braucht keine Xbase++ Vorkenntnisse um mit Express++ zu
arbeiten ... oder andersrum wird ein Express++ User nicht über das Level von Express++ raus-
kommen ... und das will der normale Express++ scheinbar gar nicht.

Das ist wirklich Unsinn.

eXpress++ erzeugt Objekte und arbeitet mit Klassen. Wer über die Migrationsstufe hinaus ist, wird sich sehr wohl mit diesem Aspekt befassen und sehr viel tiefer einsteigen. eXpress++ ist eine Technik, die aber letztlich etwas ähnliches liefert wie objektorientierte Programmierung in "native Xbase++". Um mehr aus den Anwendungen herauszuholen und dynamischere und komplexere Dialoge herstellen zu können, wird man sich früher oder später unter die Haube begeben und die Codierungsarten mischen. eXpress++ wird dieserart zum Gerüst, das man benutzt, um sich das beste aus beiden Welten herauszuholen. Dies tun auch sehr viele Nutzer. Ich würde sogar behaupten, dass der Teil, der sich nur an der Oberfläche bewegt, der kleinere Nutzerteil ist. Leute wie Michael Rudrich, Terry Wolfe, Bobby Drakos und viele andere würden Dir für diese Behauptung die Nase drehen.

Optimierbar ist eXpress++ aber natürlich dennoch. Es scheint mir allerdings wenig hilfreich, das hier zu tun, weil die Codeverbesserungen mit jedem neuen Build hinfällig wären. Wenn man verbesserbaren Code findet, sollte man das Roger melden, in dessen Board.

[Alfred]

Hallo Tom,

ich gehöre zu denen die express++ nur anwenden.

weil die Codeverbesserungen mit jedem neuen Build hinfällig wären.

Kann man denn die Änderungen nicht auslagern und zB. einen Befehl jdc....
schaffen.

Gruß
Alfred

[Tom]

Hallo, Alfred.

Kann man denn die Änderungen nicht auslagern und zB. einen Befehl jdc.... schaffen.

Damit zöge man quasi antizipierend die A*karte für den Fall, dass an Kernfunktionen oder am Reader etwas geändert würde, dass neue Optionen hinzukämen und, und, und. Wenn man das wirklich tun wollen würde, sollte man tatsächlich sein eigenes MyeXpress zusammenstoppeln und auf Updates verzichten. Die Bibliothek ist wirklich sehr komplex. Zudem reagiert Roger ja auf Anmerkungen wie "Hier machst Du zu viel des Guten" oder ähnliche. Einige eXpress++-Kunden entwickeln ja tatkräftig mit und machen so etwas.

[AUGE_OHR]

hi,

Im Grunde kann man sagen: man braucht keine Xbase++ Vorkenntnisse um mit Express++ zu arbeiten ... oder andersrum wird ein Express++ User nicht über das Level
von Express++ rauskommen ... und das will der normale Express++ scheinbar gar nicht.

Das ist wirklich Unsinn.

Ich gehe sogar noch weiter und stelle in den Raum ob 3st Party Tool User überhaupt Xbase++
User sind oder eben "nur" Express++ User. Sicherlich gibt es einige "Experten" die auch mal den
Source lesen aber die meisten User tun das ja eben nicht und DAS ist für mich der Unterschied.

Ein "Anfänger" der gleich auf Xbase++ und Express++ anfängt läuft Gefahr das er nur Express++
kann. Gibt man ihn eine reine Xbase++ Class dann steht er im Wald ... vielleicht weiss er noch
nicht mal was eine Class ist.

Deshalb gilt es immer vorher die "Betriebsanleitung" zu lesen ... aber wer macht das schon weil
sich ja die meisten damit nicht beschäftigen wollen ( ... lass das doch jemanden anderen
machen ... ).

Leute wie Michael Rudrich, Terry Wolfe, Bobby Drakos und viele andere würden Dir für diese Behauptung die Nase drehen.

... deshalb arbeiten ja auch so viele am XCodeJock Project mit...

Wenn man verbesserbaren Code findet, sollte man das Roger melden, in dessen Board.

Ich sagte doch das ich mir das so denke das evtl. Lösungen an Roger gepostet werden.

[Michael Rudrich]

Hi

>Ein "Anfänger" der gleich auf Xbase++ und Express++ anfängt läuft Gefahr das er nur Express++
>kann. Gibt man ihn eine reine Xbase++ Class dann steht er im Wald ... vielleicht weiss er noch
>nicht mal was eine Class ist.

Obwohl ich diese Gefahr überhaupt nicht sehe - doch:
Was wäre denn so schlimm daran wenn einer der super geile Software schreibt das ausschließlich
mit eXPress Commands tut?
Glaubst Du wirklich es ist für einen Anwender relevant, ob der Typ der ihm ein tolles Programm
schreibt das dafür sorgt dass seine Firma rund und ohne Probleme läuft, weiß was eine Class ist?
Interessiert das wirklich irgendeinen Kunden?

Darf ich Dich in mal was fragen was mich schon lange interessiert, Jimmy?
Aus welchem Grund programmierst Du eigentlich? Ich mein: Machst Du das um Deinen Lebens-
unterhalt damit zu verdienen oder einfach aus Spaß so nebenbei? Oder hast Du 'Forscher-Motivationen'?
Danke für eine ehrliche Antwort!

> ... deshalb arbeiten ja auch so viele am XCodeJock Project mit...

Würdest Du mir erklären wie Du das meinst? Ich bin ein wenig schwer von Begriff heute morgen, doch
wenn das eine kleine Kritik sein soll dass sich so wenig Leute engagieren kann ich nur soviel sagen:
Bisher gibt es im Rahmen meiner Lebensunterhaltverdienenden Tätigkeit nicht die Notwendigkeit,
Codejock in meine Programme zu integrieren. Das kann sich ändern - doch erst wenn es diese
Notwendigkeit gibt werde ich mich damit beschäftigen. Ich habe mit Tom zusammen in Italien mal
diese Thematik andiskutiert und FÜR MEINE Bedürfnisse recht schnell einen Weg gefunden wie ich
das angehen könnte wenn ich es müßte. Das hat mir gereicht in Sachen Codejock - intensiver
beschäftigen werde ich mich dann wenn ich es muss... bzw. wenn es als Programmierer wie auch immer
von mir verlangt wird!

Gruß
Michl

[Tom]

Hallo, Jimmy.

Ein "Anfänger" der gleich auf Xbase++ und Express++ anfängt läuft Gefahr das er nur Express++
kann.

Ja und? Dafür kommt er wesentlich schneller zu Ergebnissen. Und, wie Michl ganz richtig schreibt: Dem Endkunden kann das herzlich schnuppe sein. Was zählt, das ist eine funktionsfähige, attraktive Applikation. Ob die dadurch entstanden ist, dass man verwelkte Möhren zu einem Turm gestapelt oder puristisch mit Maschinencode herumgeeiert hat, kann dem herzlich egal sein. Und das ist es auch. Am Rande bemerkt: Es gibt in unserem Markt einige Applikationen, die sich mit dem Zusatz ".NET" schmücken, die aber erstaunlicherweise nicht eine einzige .NET-Klasse mit sich herumtragen. Auch das scheint wenige Käufer zu interessieren.

Sollte der Fall eintreten, dass sich Roger aus dem Markt zurückzieht, kann man die Lernkurve, "pures" Xbase++ zu verstehen und zu programmieren, immer noch angehen, sofern das nicht vorher oder parallel passiert ist. Davon abgesehen ist eXpress++ pures Xbase++. Es spielt letztlich keine Rolle, ob man diesen Code selbst programmiert hat oder nicht. Das gleiche Problem hätte man mit einem Stammprogrammierer, der schlecht dokumentiert und sehr viel Wissen im eigenen Schädel hortet. Wenn der die Firma verlässt, hat man den Kopf ganz schön voll. Nicht wenige kleine Softwarebuden dürften wissen, was ich damit meine. Und dabei spielt dann keine Rolle, ob dessen Code in Maschinen-Hex oder Xbase++ vorliegt oder aus lauter Aufrufen fremder Klassen besteht, die in Fortran IV geschrieben sind.

Ich verstehe Deinen Sprachpurismus, aber Du hast einfach einen anderen Ansatz als viele andere. Du hast offenbar auch sehr viel mehr Zeit als die meisten hier, die Endanwendungen schreiben, an denen sie täglich zwölf Stunden unter hohem Druck arbeiten. Ich behaupte von mir, sehr viel über Xbase++ und die von mir eingesetzten 3rd-Party-Tools einschließlich eXpress++ zu wissen, aber dieses Wissen ist entstanden, weil ich letztgenannte über die Standardfunktionalitäten hinaus nutzen wollte und musste. Das würde mich aber nie dazu verführen, Leute abzuqualifizieren, die sich nicht dafür interessieren, was ihre gekauften und bezahlten Zusatztools machen, die ihnen in der Hauptsache die Arbeit dramatisch vereinfachen.

[Jan]

Abgesehen davon: Wo fängt den Xbase++ -Purismus an, und wo hört der auf? Wenn jemand CodeJock einsetzt, dann ist das ja auch schon kein Xbase++ pur mehr.

Ich gehöre ja auch zu denen, die eigentlich alles selber machen wollen. Aus verschiedenen Gründen. Und hab mir nun doch die PDF-Klasse von Edgar besorgt. Weil ich einfach nicht die Zeit habe, das selber zu schreiben. Ist zwar auch Xbase++ pur (wie ja auch eXpress++), aber man muß das ja auch ersteinmal zusammenbekommen. Und ist mein Programm damit nicht mehr Xbase++ pur? Also ich denke: Purer, als wenn ich CodeJock einsetzen würde

Es stellt sich ja auch die Frage: Warum Xbase++ pur.

• Weil man das so will? Da kann man schlichtweg nicht gegenanargumentieren, weil das einfach so ist wie es ist.
• Weil man kein Geld extra ausgeben möchte? Wobei die eigene Entwicklungszeit ja auch Geld wert ist, wie Tom ja ganz richtig immer wieder betont, auch wenn das nicht immer und überall DAS Argument ist, wie manchmal bei mir z. B..
• Weil man nicht abhängig von anderen sein will? Nachvollziehbar, aber nicht ganz folgerichtig. Denn ich bin von noch viel mehr anderen Dingen abhängig, da bekomm ich ja auch nicht ständig eine Krise wegen.
• Weil ich Angst habe, der Lieferant der Zusatzsoftware macht irgendwann dicht, und dann steh ich blöd da? Zumindest das dürfte bei eXpress++ nicht ganz gelten, denn ich versteh das so, daß man da den Code mitbekommt. Bei Edgar habe ich mir auch den Code besorgt. Also who cares?

Abgesehen davon kann ich mir die CodeJock-Sachen auch alle selber programmieren. Was garantiert geht. Wenn ich 150 Jahre Zeit dafür habe. Aber DANN wär es wirklich Xbase++ pur.

Jan

[Tom]

Hallo, Jan.

Das würde ich alles so auch unterschreiben.

Im vergangenen Jahr habe ich dringend nach einer Möglichkeit gesucht, Bilder in allen möglichen Formaten anzuzeigen, bearbeitbar zu halten und - vor allem - bemaßen zu können. Natürlich hätte ich mich auch dransetzen und versuchen können, das irgendwie mit der GRA-Engine, XbpBitmaps undsoweiter selbst zu machen. Dann säße ich heute noch an dieser Sache, und die geschätzt 500 anderen Programmänderungen und -erweiterungen, die ich in dieser Zeit tatsächlich umgesetzt habe, wären noch auf der To-Do-Liste. Stattdessen habe ich von einer Firma, von der ich erst danach erfahren habe, dass sie in Japan sitzt, ein AX-Control eingekauft, das sich bequem einbinden lässt und das ich nach einiger Arbeit tatsächlich dazu gebracht habe, mir Informationen zu liefern, aus denen ich Bemaßungen errechnen kann (das Forum hat dabei geholfen). Insgesamt war das ungefähr eine Mannwoche Arbeit, mit allem drum und dran. Wenn dieser Anbieter jetzt vom Markt ginge oder das Tool nicht mehr laufen würde, weil es z.B. von Windows 7 nicht unterstützt wird, müsste ich mich abermals auf die Suche begeben und vielleicht wieder drei oder vier Manntage investieren (weil ich nicht mehr herauskriegen müsste, wie man die Gauß'sche Trapezformel anwendet). Damit kann ich sehr gut leben. Und ich lasse mir diese Politik auch nicht zerreden. Von den insgesamt gut einem halben Dutzend Fremdtools (eXpress++, List & Label, Flipper Graphics, Xb2.NET, SQLexpress, ImageKit, TX TextControl, CodeJock), die ich inzwischen einsetze, bin ich bisher niemals in dieser möglichen Art enttäuscht worden, und ich bin sicher, dass ich einen Weg finde, sollte das mal geschehen. Bis dahin haben sie mir dramatisch mehr Arbeit erspart als sie gekostet haben - oder als es kosten würde, wenn ich mir einen Ersatz suchen müsste. Und ich vermisse es nicht, nicht bei allen zu wissen, wie zur Hölle sie funktionieren. Das ist mir schlicht und ergreifend scheißegal.

[Markus Walter]

Hallo, Jan.

Das ist mir schlicht und ergreifend scheißegal.

ein echter "Tom"...

[Martin Altmann]

Hallo Markus,
yup - aber der darf das, hier geniesst er ja Hausrecht!
Und mir gibt er auch gerne Tiernamen - zwar meist verbunden mit einem bestimmten Adjektiv, aber das werde ich hier mal lieber nicht kundtun

Viele Grüße,
Martin

[Koverhage]

Ich würde das auch so unterschreiben.
Ich arbeite zwar hauptsächlich mit Express++ und zwar aus folgenden Grund:

Es gab damals 2 Möglichkeiten zu Zeiten von Xbase++ 1.3 bzw. auch für OS/2 , entweder unsere Anwendung in Windows anzubieten, oder keine Anwendung mehr verkaufen.

Xbase++ war zwar vorhanden, klar hätte man das "einfach " mit Xbase++ compilieren können, aber der Kunde hätte immer noch DOS gesehen. Die Umstellung auf GUI hätte schlichtweg zulange gedauert.

Also Express++ gekauft und relativ wenig Aufwand gehabt.

Natürlich gibt es Situationen wo ich kein Express++ einsetzen kann, da muss ich dann zwangsläufig "pures Xbase++" (was Express++ ja auch ist) beschäftigen.
Aber was soll es, ich habe den Quellcode, so wie jeder Express++ Anwender.

Wie Tom schon sagt, schneller kann man doch nicht zum Ergebnis kommen.

Jimmy, Du setzt doch auch List&Label, MapPoint, etc. ein. Sind das keine Zusatztools ?

[Tom]

"Scheißegal" darf hier jeder sagen - einfach mal ausprobieren. Das hat nix mit Hausrecht zu tun.

[Michael Rudrich]

Versuch:

Scheissegal