Inoffizielles deutsches Xbase-Forum

Hallo Werner,
danke werde ich probieren.

ich habe gottseidank keine Probleme (1.9 355 SL1)
Aber....
Bei einem Betriebssystem von Microsoft (!) das noch keine 2 Jahre auf dem Markt ist dieses als
"Mindestanforderung" zu verlangen ist doch nicht machbar.
Bis vor einiger Zeit gab es noch Probleme bei der korrekten Netzwerkanbindung an MICROSOFT Server (2012, 2016)
Einem Kunden klar machen dass er seinen Rechner kostenpflichtig updaten muss obwohl der noch keine 3/4 Jahre alt ist
dürfte ebenso schwer sein.

Wir haben nach unserem letzen Update die Kunden, die noch XP-Rechner einsetzten, quasi "gezwungen" auf ein neues Betriebssystem
bzw. neuen Rechner umzusteigen und das Geschrei bei den betreffenden Personen war groß....

Gruß Stefan

@Stefan
bei meinen Kunden die ich betreue sind bis auf wenige PCs alle schon lange auf Win10 umgestellt, teils von Anfang an. Und fast alle haben inzwischen das aktuellen 1703er Update.
Die wenigen PCs deren Betriebssysteme nicht auf dem aktuellen Stand sind können entweder kein Windows 10 64Bit mehr oder müssen XP bzw. DOS haben weil alte CNC-Maschinensteuerungen nicht mit neueren Win-Versionen arbeiten.
Der eine oder andere welcher das Update nicht mehr kostenlos bekommen hatte war nicht sehr erfreut darüber dass ich das Updaten verschlafen hatte und der die Lizenz zahlen musste - wurde aber auch überall gemacht.

DelUser01 hat geschrieben: ↑Do, 29. Jun 2017 18:54Der eine oder andere welcher das Update nicht mehr kostenlos bekommen hatte war nicht sehr erfreut darüber dass ich das Updaten verschlafen hatte und der die Lizenz zahlen musste - wurde aber auch überall gemacht.

em ... äh ... dann google doch mal wie man "jetzt noch" einen Win7 PC "kostenlos" nach Windows 10 bekommt (wenn es die Hardware mitmacht)

Hallo Stefan

Bei einem Betriebssystem von Microsoft (!) das noch keine 2 Jahre auf dem Markt ist dieses als
"Mindestanforderung" zu verlangen ist doch nicht machbar.

Stefan das ist gar kein Problem. Im Gegenteil. Das war super einfach.
Keiner meiner Büroanwender wollte bei Win7 bleiben im Gegenteil nach Ablauf des kostenlosen Updates waren alle schon längst auf Win10.
Niemand trauert heute noch Win7 nach .......

Ich kenne nur noch einige Win7 32Bit PC's wegen Steuerungsprogrammen die nicht Win10 und 64 Bit tauglich sind.

Gruss Carlo

das kann ich nicht verstehen. Die Kacheln sind doch nur doof im Vergleich zu der schönen win 7 Oberfläche

Hubert,
genau meine Meinung

Kacheln? Fliesen?

Also, Hubert - solange Du nicht in den Tablet-Modus wechselst, kriege ich nichts von Kacheln mit (zumindest nicht, nachdem ich das Start-Menü aufgeräumt habe). Die Oberfläche ist doch nach dem Windows 8-Debakel wird zurückgebaut worden.

In der Zwischenzeit ist der PDR geschlossen mit dem Build 807. Vor 2 Stunden war der noch offen. Mal schauen ob Alaska das damit hinbekommt wie von denen erhofft das Update heute noch raus zu bekommen.

Jan

... 807 ist heruntergeladen und wird gerade installiert.

Jan

Hallo Zusammen !

... 807 ist heruntergeladen und wird gerade installiert.

Mein gemeldeter Fehler beim Beenden der Workbench bei geöffnetem Debugger-Variablen-Fenster das nicht gedockt ist wurde auch behoben

Und die in der Roadmap angekündigte EXTERN-Funktion ist auch vorhanden.
Damit ist die umständliche Kombination von DllLoad() und DllCall() bzw. DllPrepareCall und DllExecuteCall zum Definieren und Ausführen von W32API-Funktionen nicht mehr nötig.
Damit geht das Verwenden der W32API-Funktionen genauso leicht wie in VFP und in Verbindung mit DllCallback sogar noch besser. Das nenne ich einen wirklichen Fortschritt.

Hallo Hans-Peter

Der Extern Call war doch schon lange ohne DllLoad() etc. möglich:
Das neue Extern ist leider nur für "einfache" Call geeigent. Schön dass auch Rückgabepameter String möglich ist.
Leider ist EXTERN für sehr viele viele Ding unbrauchbar da die DLL geladen, Befehl ausgeführt und die DLL ENTLADEN wird.

So jedenfalls die Beschreibung.

Abläufe mit mit mehreren Handles und mehreren Prozessen / Calls einer DLL für eine Arbeit scheinen damit nicht möglich. Das die DLL ja sofort entladen wird.


Gruss Carlo

Hallo

ich habe heute die neue EXTERN getestet.

Dazu habe ich ein Programm umgeschieben das verschiedene Funktionen einer DLL aufrufen muss um zu einem Ergebniss zu kommen.

Die vielen Call's über EXTERN haben einwandfrei gearbeitet.
Die DLL wird anscheinend am Ende der EXTERN doch nicht wie beschrieben entladen.

Da die Load und Unload Funktionen so nicht nötigt sind habe ich auch keinen Weg gefunden den durch die DLL belegten Speicher freizugeben......

So weit die ersten Tests.


Gruss Carlo

Hallo zusammen

Nach Rücksprache mit Steffen Pirsig hat er mir bestätigt, dass es auch für die Version 1.90SL1 einen Patch geben werde. Der Zeit-Horizont liege aber bei mindestens 4 Wochen.

Gruss
Marco

ramses hat geschrieben: ↑Sa, 01. Jul 2017 20:58 Die vielen Call's über EXTERN haben einwandfrei gearbeitet.
Die DLL wird anscheinend am Ende der EXTERN doch nicht wie beschrieben entladen.
Da die Load und Unload Funktionen so nicht nötigt sind habe ich auch keinen Weg gefunden den durch die DLL belegten Speicher freizugeben......

EXTERN klingt wirklich gut, alle möglichen Parameter können übergeben und empfangen werden ... (soweit ich das bei kurzer Durchsicht beurteilen kann).

Wegen dem Speicher würde ich mir keine Sorgen machen !

Wenn die EXE beendet wird wird aller Speicher freigegeben.
Wenn die DLL sauber geschrieben ist, wird auch dort der Speicher freigegeben, sobald eine Funktion sauber beendet wurde.

Bei der QuickPDF DLL habe ich anfangs auch DllUnLoad() - mit ot4xb - benutzt, weil ich dachte das wäre sinnvoll.
Dem war aber nicht so !
Diese DLL hat internen Speicher erst freigegeben, sobald die EXE beendet wurde.
Nach einem DllUnLoad() und erneutem Dllload(), wurde erneut interner Speicher für die Anwendung belegt, nicht wirklich viel, aber wenn ich 10.000 Durchläufe gestartet habe ... doch erheblich.

Ohne DllUnLoad() lief alles perfekt, die Anwendung schwankte um den Startwert der Speicherbelegung.

Nach dem Ende der EXE war der Speicher immer freigegeben worden.

Nach Rücksprache mit Steffen Pirsig hat er mir bestätigt, dass es auch für die Version 1.90SL1 einen Patch geben werde. Der Zeit-Horizont liege aber bei mindestens 4 Wochen.

eine sehr, sehr gute Nachricht am heutigen Morgen - Danke für die Info

jetzt sind wir alle gespannt, wie und wann es umgesetzt wird.

Scarmo hat geschrieben: ↑Do, 06. Jul 2017 7:59Nach Rücksprache mit Steffen Pirsig hat er mir bestätigt, dass es auch für die Version 1.90SL1 einen Patch geben werde. Der Zeit-Horizont liege aber bei mindestens 4 Wochen.

Huch! Das ist ja mal eine positive Überraschung. Mir war nämlich explizit genau das Gegenteil gesagt worden. Ich weiß allerdings nicht von wem, denn der Support von Alaska hat seit einiger Zeit die sehr unschöne (und unhöfliche) Eigenheit, nicht mehr den Namen unter die Mails zu schreiben.

Jan

Huch,

Schade dass Alaska mit dem Patch für 1.9 Zeit in ein "überholtes Produkt" steckt anstatt diese Zeit in die aktuelle Version zu stecken.

Unverständlich. Zeigt dass das Sie für die 2 bezw. sich selbst längerfristig keine Zukunft mehr sehen?

Ist ja etwa so wie wenn wieder von All-Ip zuruck zu POTS (Analog) gewechslt würde.

Hoffentlich wird dieser Patch dann wirklich nur an User mit aktiver Sub. verteilt ....... alles andere wäre dann überhaupt nicht mehr verständlich!

Gruss Carlo

hi,

die Frage ist doch ob Alaska "Schuld" hat an dem BUG oder nicht.

IMHO M$ "verändert" keine API ... wenn wird die erweitert ...
oder die API ist ""decipated" aber hatte (bislang) noch funktioniert und nun nicht mehr.

wenn es sich um einen "alten" BUG handelt dann hätte der schon vorher behandelt werden müssen !
verantwortungsvolle Firmen bringen dann auch noch für "alte" Versionen einen Patch s.h. M$ bei Windows XP

p.s. wie aus der Umfrage nach verwendeten OS() zeigt laufen noch viele Xbase++ Apps auf "älteren" OS()

Hallo Jimmy

bitte bedenke:
a) Alaska hat nie behauptet 1.9 würde auf W10 laufen
b) Der Patch von XP hat nichts mit Verantwortung zu tun, lediglich das Stopfen einer 17 Jahre alter Lücke durch die es zu TOTALEM Datenverlust auf dem Rechner kommen könnte. Wohl auf Druck der Gerätebauer aus dem Medizin Bereich?

Zwischen einem Anwenderprogramm das nicht läuft und einer Sicherheitslücke im System die zu Daten-Totalverlust führen könnte ist doch ein gewaltiger Unterschied.

Ich kann es aus Sicht des IT-ler immer weniger verstehen dass sich "Fachleute" verzweifelt an ein 7-10 jahre altes Tool krallen, wo mann/frau weiss dass die 2.0 alles was die 1.9 konnte auch kann, einfach ohne viele Probleme.

Spätestens mit dem aktuelle Bug müsste doch jedem klar werden die Zeit der 1.9 ist vorbei ....... Das festhalten an der 1.9 kostet doch nur Nerven, Geld und Ansehen ...... Kunden sind nicht dumm, die sehen doch auch das die DLL's alt, sehr alt sind.

Gruss Carlo

Kunden sind nicht dumm, die sehen doch auch das die DLL's alt, sehr alt sind

Neuer muss ja nicht unbedingt auch besser heissen... und Datumeinträge lassen sich ändern.

ramses hat geschrieben: ↑Do, 06. Jul 2017 18:00Kunden sind nicht dumm, die sehen doch auch das die DLL's alt, sehr alt sind.

was sagt eine Xbase++ v2.x App unter Windows 10 bei "Betriebssystemkontext" ich wette das MDIDEMO.EXE dir Windows Vista anzeigt

p.s. jeder ordentlich programmierte Sprache, die auf der Windows API beruht, sollte in jeder Windows Version laufen

Hallo JImmy

was willst du mir damit mitteilen?



Ich sehe du verwendest Total-Commander sicher eine neue Version.

p.s. jeder ordentlich programmierte Sprache, die auf der Windows API beruht, sollte in jeder Windows Version laufen

Würde in diesem Fall bedeuten dass auch die V5.5 einwandfrei laufen müsste. tut Sie aber nicht, grosse Probleme und Fehler.



Gruss Carlo