Zwickmühle

[sherlogg]

Wo kann ich die denn bekommen?

Einfach eine Mail an Roger schreiben.

Danke Tom

[AUGE_OHR]

Ich habe mir auch WinDev angeschaut und auch mal die Trial herunter geladen.

suche doch mal nach WinDev hier im Forum. du wirst da ein Menge Informationen finden.

[Herbert]

Vielleicht noch eine Frage an Herbert aus Österreich:
Ich habe mir auch WinDev angeschaut und auch mal die Trial herunter geladen. Auf den ersten Blick haut einen die Menge an Informationen komplett weg. Wie schätzt Du denn den zeitlichen Aufwand sich einzuarbeiten? Englisch ist kein Hindernis. Ich habe zwar jetzt auch angefangen, die ganzen, mitgelieferten Dokus anzuschauen, aber es wäre natürlich toll, von jemandem, der das schon hinter sich hat, eine Einschätzung zu bekommen!

Ich will nicht abwerben. Kenne viele hier, die mir geholfen haben., Nur eben bin ich mit Sbase stecken beglieben in der Weeiterentwicklung und wäre heute wohl nicht da wo ich jetzt bin.
Schicke dir PN.

[sherlogg]

Hallo Zusammen!

Nochmals Dank für die vielen und aufschlussreichen Antworten.

Mal sehen, in welche Richtung es geht!

LG, Dieter

[ramses]

Hallo Dieter

ich würde mir ernsthaft überlegen das ganze mit xb2net als Web-App (html) aufzubauen und das ganze xbase-gui zu vergessen.
Ich habe meine Warenwirtschaft so umgestellt und würde niemals zurück zu einem gui-Desktopprogramm.

Cu Carlo

[UliTs]

Hallo Dieter

ich würde mir ernsthaft überlegen das ganze mit xb2net als Web-App (html) aufzubauen und das ganze xbase-gui zu vergessen.
Ich habe meine Warenwirtschaft so umgestellt und würde niemals zurück zu einem gui-Desktopprogramm.

Cu Carlo

Das hört sich interessant an! Bist Du beim User-Meeting in Bamberg?

[Rudolf]

Hallo,
es würde mich echt interessieren wie man eine halbwegs professionelle WAWI ohne extreme Einschränkungen in Bedienung und Funktione auf Web umsetzen kann. Ich kann nur von meinem System ausgehen, da würde alleine die Umsetzung der Artikelverwaltung gewaltig scheitern. Nicht weil es nicht lösbar ist, aber weil der Aufwand extrem hoch ist und ich keinen Sinn darin sehe das Programm in der Bedienung extrem einzuschränken. Ich arbeite auch mit TSplus, damit ist jedes Xbase++ Programm sogar über jeden HTML5 Browser perfekt bedienbar. Wozu dann der ganze Aufwand mit den resultierenden gravierenden Einschränkungen ?
Grüße
Rudolf

[ramses]

Hallo Rudolf

so gross sind die Einschränkungen nicht. MIt Soap/Ajax ist sehr viel möglich. Die grossen Vorteile überwiegen. Meiner Meinung nach ist die PC Ära zu Ende. Gefragt sind Tabelets und Zugriff mit Smartphone und die Freiheit "Arbeit von überall". z.b. auf dem weg zur Arbeit im Zug....

Eine WebAnwendung brauchst du nicht auf jedem PC zu installieren. Ein Link reicht für ein Zugriff aus. Gerade bei den jüngeren Entscheidungsträger die nun langsam an die Macht kommen schneidest du mit jedem PC Programm von vornehin gewaltig schlechter ab als mit einer Web-App. So jedenfalls meine Erfahrung. Da helfen auch Citrix uva. nicht weiter. Von meinen letzten "Neukunden" wollten alle die Web-App......

Sicher am Anfang ist der Aufwand für eine Tool-Sammlung / Grundfunktionen und vorallem für das EIGENE UMDENKEN aber danach bist du mit der Entwicklung schneller als mit den allgesammt mühsamen Formdesigner für xbase code besonders mit der neuen Laufzeitcompilierung von xb2net ist die Entwicklung viel einfacher geworden.

Es würde mich interessieren an was deine Artikelverwaltung denn "gewaltig Scheitern würde" ?

CU Carlo

[Rudolf]

Hallo Carlo,
mit Ajax könnte es vielleicht klappen die Grundfunktionen umzusetzen, aber trotzdem schwierig da bei mir viele Interaktionen in den Dialogen notwendig sind. Meine Dialoge haben inkrementelle Suche über verscchiedene Indizies und Tabs für die verschiedenen Artikeldaten wie Preise, History, Seriennummern, Dokumente, Transaktionen etc. Bei Änderungen im Dialog müssen sofort alle relevanten Parts upgedatet werden (verschiedene Browser mit Tabellen, Textfelder etc.) Die Geschwindigkeit bei der Anzeige schaffe ich sicher nicht übers Web. Den Komfortverlust würden meine Kunden nicht akzeptieren. Mit eXpress++ kann ich die komplexen Dialoge relativ einfach erstellen. Außerdem haben meine Kunden immer noch kein gutes Gefühl wenn Ihre Anwendung im Netz steht, auch wenn die Sicherheit durch XB2NET garantiert ist. Ist einen reine Gefühlssache, vor allem bei älteren Generationen. Kennst Du TSplus ? Damit lässt auch über normalen Browser jede Anwendung perfekt bedienen. Ich sehe also nicht viele Vorteile die den Aufwand wert wären eine Web Applikation aus einem komplexen Prograrmm zu machen.
Grüße
Rudolf

[ramses]

Hallo Rudolf

Nein, TSPlus kenne ich nicht. Aber wenn Fernbedienen heisst ein Programm fernzusteuern hilft dies auch nicht weiter bezw. ist nicht das selbe wie eine Web-App die ja eigenlich nur aus einem Dienst auf einem Server besteht.


Deine Bedenken und die deiner Kunden kann ich verstehen. Die hatte lange Zeit auch.
Bis der Chef (Ü60) meines Hauptkunden mit mehreren Aussenstellen (die wir wegen langsamen Internet untereinander mit mehreren Server mühsam synchronisierten) mich eines Tages zur Besprechnung einlud und sprach: "So gehts nicht weiter....... Der Aussendienst braucht aktuelle Daten die Aussenstellen auch, tu was oder ich suche eine Alternative ......."

Was denkst du? Wie gross war unsere die Panik damals. Genau dies was der Impuls zum Umdenken. Ohne dieses Ereigniss würde ich deine Einwände gegen Web-Apps noch heute Diskusionslos und ungesehen sofort unterschreiben.

Sicher sind komplexe Dialoge sind auch in einer Web-App möglich brauchen einiges mehr an Code als einer mit eXpress++ erstellter aber wenn du das Gerüst, dieses Toolset einmal hast geht es.

Ich habe auch inkrementele Suche, für die gleichen Dinge wie du, die sind absolut Problemlos. (Jetzt, nach harter Arbeit am Code, wohlgemerkt.)

Auch die Rechteverteilung kannst du z.b. nach IP Adressen ergänzen. zb. Funktion kann nur lokal benutzt werden usw.

Heute gibt es im Hauptsitz der Firma noch 1 aktiver Server und einen Backupserver, die Lageristen/Staplerfahrer haben Tablets, 2 Arbeitsplätze (Dateneingabe Kontrolle) konnten aufgelöst werden.
Die Aussendienstler können Bestellungen beim Kunden aktuell direkt erfassen und der Chef muss auch nicht mehr immer im Betrieb sein. Nur Vorteile. Nachteile keine.

Meiner Meinung nach liegt die Zukunft einzig bei "Browserbasierenden Programmen" ...... Wenn wir kleinen Programmierer (Kleinfirmen) nicht auf diese neue Technik umstellen werden wir untergehen und durch Cloudlösungen abgelöst. Insbesonders wenn wir unsere Zahlenden Kunden noch mit Dongles, Kopierschutzen, an die Hardwaregefesselten Programm und vielem andern Schikanen drangsalieren oder schlicht Erpressen.


CU Carlo

[satmax]

Auch ich überlege immer wieder in Richtung browserbasierender Lösung, finde aber noch keinen richtigen Ansatz. Das ich breits jetzt auf SQL setze ist sicher kein Nachteil. Was mir fehlt sind Beispiele zum Angreifen. Ähnlich dem TopDown Demo wo man praktisch alle Möglichkeiten im Demoprogramm sehen und testen kann.

[ramses]

@SatMax

Hallo Markus

lade dir doch mal die Demo von XB2net herunter.

Da sind Beispiele dabei welche dir die Grundfunktionen zeigen.

Vorallem vergiss CXP von Alaska das scheint eine Dokumentationslose Totgeburt zu sein......(Meine Meinung)

Cu Carlo

[satmax]

Danke, hab ich nun gemacht. Das Problem ist das Gleiche. Ich suche Beispiele mit allen Standardcontrols, get, tab, brows, listbox,.... Davon ist praktisch nichts enthalten.

[Herbert]

passt auf, nicht von einem zu programmtechnisch gesehen zu systemlastigen Tool ins nächste zu schlittern.

[ramses]

@satmax

Hallo Markus

eine Antwort auf deine Suche/Frage ist nicht so einfach in kürze zu schreiben. Eine Web-App und der Browser kommunizieren über html Meldungen / Befehle miteinander. Ab besten suchts du Literatur über Web-Seiten Design / HTML / CSS da sind die vielen Möglichkeiten beschrieben. Oft hilf auch sich den "Seitenquelltext" einer Seite z.b. dieser Seite im Browser anzeigen zu lassen. (Rechtsklick)

CU Carlo

[Rudolf]

Hallo
eXpress++ hat einen guten Ansatz mit den DC_Html*() Befehlen. Ich bevorzuge aber HTML Templates z.B. mit jQuery mobile. Ich erstelle vorher den Dialog als normales HTML und ersetzte dann Teile durch Platzhalter z.B. für Tabellenzeilen die ich beim Aufruf dann fülle. Mit dem neuen XB2NET kann ich alles über die compilierten Scripts machen.

Grüße
Rudolf

[Lewi]

Hallo Dieter,
ich bin vor fast 4 Jahren von xBase auf WinDev umgestiegen.

1. Einarbeitung
Grundsätzlich ähnelt die WinDev-Syntax den xBase- Sprachkonstrukten und ist genauso "simpel". Zudem bietet WD hunderte von teilweise sehr mächtigen Funktionen, zu denen es keine xBase -Entsprechungen gibt. Ferner sind die visuellen Controls wie Eingabefelder, List-Boxen, Tabellen usw. in WD weitaus leistungsfähiger als die Controls in xBase.
Allerdings muss der Entwickler sich zunächst mit der "Ablaufsteuerung" von WD beschäftigen und verstehen, d.h., wie und welcher Reihenfolge werden die Controls initialisiert und mit Werten befüllt. Ist die (leichte) Hürde genommen, geht es mit der Programmierung ziemlich zügig voran. Ich selbst habe mich seinerzeit ca. 3 Monate mit den Grundlagen von WD beschäftig und habe die Funktionsweise aller Controls studiert und für mich Beispiele entwickelt. Danach hatte ich begonnen, meine erste größere xBase-Anwendung in WD umzusetzen.

2. Umsetzung einer xBase-Anwendung
Eine Portierung einer xBase-Anwendung mit irgendwelchen Tools auf Code-Ebene ist nicht möglich. Ferner müssen alle existierenden Formulare mit dem WD-eigenen Formulargenerator neu entwickelt werden.
Für eine xBase-Anwendung mit ca. 100.000 Zeilen Code habe ich 6 Monate (Full-Time) gebraucht. Fehlerbeseitigung und die Test zogen zusätzlich 6 Wochen Zeitaufwand nach sich. Die neue WD-basierte Version war zudem anwendungsfreundlicher und leistungsfähiger als mein xBase Pendant.

3. Qpo vadis xBase und ALASKA?
Eine Vielzahl von FP-Entwicklern sind mittlerweile auf WD umgestiegen (mein Eindruck aus diversen internationalen WD-Foren) , da die Art und Weise, wie FP den Entwickler bei der Codierung und Masken- und Formlar-Entwicklung unterstüzt(e), WD ziemlich nahe kommt. Es stellt sich der Frage, ob der Aufwand, den Alaska für die FP-Konvertierungen vertreibt, unternehmerisch rechnen wird.
Ich persönlich rechne eher nicht mit einer xbase-Renaissance . Ob sich die finanziellen und Ressourcenseitigen Aufwendungen, die Alaska hinsichtlich der Gewinnung von FP-Entwicklern aufwendet, glaube ich eher nicht. Die Frage ist, was bietet xBase FP-Entwicklern?
In vielen Belangen ist xbase++ technologisch und von der Leistungsfähigkeit nicht mehr auf der Höhe der Zeit. Von Themen wie "Universal App unter Windows 10" und Cloud-Anbindung habe ich von Alaska noch nichts gelesen. Ferner mangelt es xBase an Standardfunktionen und Controls wie z.B. USB-Funktionen, Standard-Funktionen zum Lesen und Schreiben von Bar- und QR-Codes, PDF-Generierung, native XML-Funktionen, Archiv-Datei-Unterstützung(ZipFile), Replikation, Implementierung von Web-Diensten, Report-Generator, eMail-Funktionen, Control für Gantt-Diagramme, Timeline, Daten-Grid, Pivot-Tabellen. Termin-Planungs-Control, Slider-Controls , RTF-Control , Chart-Control ... Die Liste könnte ich noch weiter ausführen. Die xBase-IDE ist hinsichtlich Produktivität und Development Life-Cycle meilenweit z.B. von der WD oder MS-Visuell xxx Workbench entfernt. Und auch der IDE von FoxPro aus dem Jahre 2009.
Wer heute eine Entscheidung über eine neue Entwicklungsumgebung treffen muss, der wird sich sicherlich nicht für ALASKA xbase++ entscheiden. Was spricht denn auch für xBase++? Für eine Portierung einer alten DOS Clipper-Anwendung, die 1:1 auf die 32 Bit-Welt gehievt werden soll, ist xBase++ sicherlich die richtige Wahl. Aber eine DOS Clipper-Anwendung auf eine moderne GUI umzustellen gleicht faktisch einer Neu-Entwicklung. Und aus meiner Sicht solltest Du Dir und Dein Kunde die Frage stellen, wie technologisch zukunftssicher die Anwendung nach Fertigstellung auf die nächsten 3 Jahre sein soll und wie das mit der gewählten Entwicklungsumgebung nach dem heutigen Stand der Dinge umgesetzt werden sollen.
In diesem Zusammenhang habe ich aktuell die Technologie-Partner-Seite von ALASKA evaluiert. Man findet u. a. tote Links zu „Technologie-Partnern“ oder es stellt sich die Frage, warum einige Firmen überhaupt aufgeführt werden. Des Weiteren sind Firmen wie Xb.Net, Claton, Donnay Software mehr oder weniger 1-Mann Companys. Was ist, wenn bei Alaska der Keyplayer (Steffen?) ausfällt oder bei den anderen 1-Mann Shows? Wie schnell so etwas gehen kann, zeigt das Beispiel „FRAX“.

Vielleicht konnte ich Dir einige Denkanstöße geben.

Viele Grüße
Olaf

[Armin]

Hallo,

wir haben eine Umsetzung mit dem WAA gemacht und sind sehr zufrieden. Nach meiner Erfahrung lässt sich damit so ziemlich alles in HTML(5), css und Javascript abbilden.
Ungefähres Vorgehen:
- HTML-Templates als Vorlagen per WAA ausfüllen (damit per Tool stylebar!)
- Möglichst kein HTML per WAA schreiben
- ausgefülltes HTML mit Javascript an den Client senden
- das angezeigte HTML per HTTPRequest dynamisch aktualisieren usw.

Wir haben viele Detaillösungen und Varianten getestet und programmiert. Wenn jemand dazu Fragen hat... ich bin auch in Bamberg (auch mit jQuery und jQueryUI).

Da der Dateizugriff direkt auf dem Server stattfindet ist keine zusätzliche DB wirklich nötig (hohe Geschwindigkeit). Dokumente bereiten wir z.B. als PDF auf und zeigen diese im Browser.

Der Nachteil vom WAA zu XbNet ist, dass der WAA standardmäßig nicht als Dienst läuft, so dass der Server angemeldet sein muss. Man kann den WAA aber auch per Dienste-loader als Dienst laufen lassen.
Mit dem Apache als HTTP-Server bleibt eigentlich kein Wunsch offen.

Achja, die größte Schwäche von Xbase++ ist nach meiner Ansicht die fehlende durchgängige UTF8-Unterstützung.
HTTPRequest wird in UTF8 durchgeführt. D.h. immer wieder hin- und her wandeln.

Grüße, Armin

[Armin]

Hallo Markus,

Ich suche Beispiele mit allen Standardcontrols, get, tab, brows, listbox,....

das braucht man nicht - das ist alles in HTML. HTML per Servercode zu schreiben scheint zwar am Anfang verführerisch, hat aber nach meiner Erfahrung nur Nachteile.
Wir füllen hauptsächlich nur Inhalte per id ein.
Zeilen von Tabellen werden von einer Vorlagenzeile kopiert. Ebenso z.B. wiederholende DIVs werden auch aus einer Vorlage genommen, geklont, ausgefüllt und angehängt.
Für diese Zwecke haben wir auch eine Klasse gebaut, die diese Arbeiten übernimmt.

Ob jetzt Xb2Net, WAA, cxp, ... ist eigentlich unerheblich.
Und das läuft in allen gängigen Browsern. Damit sind auch verschiedene Bildschirmgrössen kein Problem.

Grüße, Armin

[Herbert]

Stimme Lewi punkto Produkteumfang und Effektivität bei.
Viele Einträge hier im Forum zeigen auf sehr tief Technisches. Dies wird mit WinDev Vergangenheit und genau das bedeutet einen gewaltigen Zeitgewinn.

Ich bin der Meinung, wenn schon eine neue Version entstehen soll (bei Wechsel auf echtes GUI ohnehin zwingend), wird das Umprogrammieren mit entsprechender Erfahrung recht schnell. Ich habe auch etwa 6 Monate gebraucht für mein grösstes Programm, dabei aber die Bedienerführung wesentlich verbessert und den Funktionsumfang deutlich erhöht (Dashboard, Office-Menüs, Toolbars, Unicode-Unterstützung, TAPI usw.). Wichtig auch, dass ich auf bestehende DB-Systeme zugreifen kann (für mich insbeso. MS SQL-Server).
Ohne diesen Umstieg hätte ich gegen meine wichtigsten Mitbewerber entscheidend Boden verloren. Jetzt sind die hinter mir her...
Allerdings konnte ich dies nur deshalb so vornehmen, weil ich keine externen Tools verwendete. Express-User oder viel Owner-Drawing (wer Teile von Tom's App kennt, weiss dass man damit Schönes bauen kann) wirken sicher erschwerend, da man Code-Abhängig wird.

[Manfred]

Hi Armin,

nächstes Jahr bist Du reif.... Dann wird ein Vortrag fällig von Dir.

[brandelh]

Wie füllt Ihr die Daten per ID genau aus, hast du da ein Beispiel ?

Ich habe immer Platzhalter im Code z.B. {NAME} und nehme StrTran(...), aber bei Tabellen muss ich viel mehr in Code lagern als mir lieb ist.

[Armin]

Hallo Hubert,

z.B. so z.B. pro id:

Code: Alles auswählen

::oDocument := HTMLDocument():loadFile("test.htm")
oElem := oDocument:GetElementByID("spanTest1")
oElem:value := "Hallo"

Tabelle:

Code: Alles auswählen

oTabelle := ::oDocument:getElement("TABELLE")
if oTabelle <>NIL
   oRow:= oTabelle:Rows[2]:Clone(NIL)
   oTabelle:Rows[2]:Destroy()
   for j := 1 to len(::aTabelle)
        oNewRow := oRow:Clone()
        for i:= 1 to len(::aTabelle[j])
             If  oNewRow:GetElement( alltrim(str(i))) <> NIL
                oNewRow:GetElement( alltrim(str(i)) ):setcontent( alltrim(etos(::aTabelle[j][i])))
             Endif
         next
         oNewRow:SetParent( oTabelle )
   next
endif

Grüße, Armin

[brandelh]

Sehr interessant, und woher kommt die Funktion HTMLDocument() ?

[Armin]

Hallo Hubert,

aus: HTML Reflection Framework (HRF)
hrf.dll


und so das oDocument an den Client senden:

cDatei:= oDocument:toHTML()
oHTML:put(cDatei)

so kann man das HTML speichern:
oDocument:saveFile( )

hier kommen auch z.B. diese Methoden her:
:getElement()
:getElementById()
:getElementByName()
:getElementsByName()

Grüße, Armin