Fragen an Alaska

[Tom]

Liebe Forengemeinde,

aus gegebenem Anlass greife ich eine Anregung von Steffen Pirsig (beim Deutschlandtreffen 2009 in Rösrath) auf und werde eine Liste mit Fragen sammeln, die ich innerhalb der nächsten zwei Wochen Alaska Software stellen werden, günstigstenfalls im Rahmen eines längeren Telefongesprächs. Also: Was fehlt Euch? Was bedrückt Euch? Was würdet Ihr gerne wissen? Was versteht Ihr nicht? Und so weiter. Wer seine Fragen nicht hier im öffentlichen Bereich stellen möchte, schickt sie mir bitte als Privatnachricht, ich stelle sie dann als anonyme Fragen in diesen Thread. Die Frist für die Fragenabgabe endet am 26. Februar, also heute in einer Woche. Bei Erfolg der Aktion werden wir sie im Quartalsrhythmus wiederholen. Ich kann leider nicht garantieren, dass jede Frage auch zufriedenstellend beantwortet wird, aber Versuch macht kluch.

[Manfred]

Hm,

stand nicht mal ein Chat zur Diskussion, in dem wir dann (moderiert) mit Steffen diskutieren sollten? Oder verwirren mich jetzt meine grauen Gehirnzellen?

[Tom]

Hallo, Manfred.

Stimmt, danke für das Auffrischen der Erinnerung. Vielleicht lohnt es sich ja, beides mal auszuprobieren. Ansonsten werde ich gleich mal bei Steffen anfragen, ob und wann er Zeit für eine Chatrunde hätte.

[brandelh]

Chat ist halt immer nur zur aktuellen Stunde und danach is nix mehr mit nachlesen.
So ein Forum archiviert ... wenn man die Suche nutzt

[Manfred]

Ja Hubert,

Du hast ja recht. Aber ein Chat hat den Effekt der Spontanität. Es entwickeln sich vielleicht Fragen aus dem Moment heraus. Und Speichern? Das müßte doch irgendwie zu machen sein, oder? Wir leben doch im Zeitalter der EDV. Zumal doch ein anderer Chat als der hier zur Diskussion stand. Meine ich mich erinnern zu können.

Es war ja auch nur mal so eingeworfen. Letztendlich entscheidet evtl. der, der das alles organisiert.

[Tom]

Hallo, Manfred.

Chats kann man protokollieren - und dann die Protokolle (oder Zusammenfassungen) der Allgemeinheit zur Verfügung stellen, vorausgesetzt, alle Teilnehmer sind damit einverstanden. Aber Chats mit mehr als sieben, acht Teilnehmern werden schnell unübersichtlich, außerdem hängen sie sehr an der Tippgeschwindigkeit des einzelnen. Ausprobieren könnte man es dennoch. Wenn ein Chat mit Steffen der Fragerunde bevorzugt wird, machen wir halt einen.

[AUGE_OHR]

hi,

ich hätte eine ganze Liste von Wünschen, wobei Alaska davon meisten schon eine Demo vorliegt, aber ich denken wir sollte "woanders" anfangen.

"Das" Problem mit Alaska ist doch die Kommunikation und das muss sich zuerst ändern damit wir uns "jederzeit" melden können ... so wie hier im Forum.

Alle registrierten Xbase++ User melden sich doch mit ihrem User Namen an der Alaska Website sowie der Newsgroup an.
Innerhalb der Newsgroup könnte man nun einen, nur für die registrierte Xbase++ User, PDR und beta = HotHotfix Bereich machen.

In diesen Bereich sollte dann auch ein "BUG Demo" Upload Bereich sein d.h. wenn man meint eine BUG gefunden zu haben UND
ein Demo gemacht hat damit es "andere" Xbase++ User "gegen-testen" könnten ... incl. Alaska.

Alaska soll also uns Xbase++ User "mehr" einbinden und uns "auf dem laufenden" halten, so wie wir es hier mit dem Forum versuchen.
Hierbei meine ich nun nicht irgendwelche Roadmaps sondern Informationen "aus der Praxis" die uns auch helfen Fehler zu vermeiden
wenn wir die "möglichen Fallen" kennen würden.

Wenn also ein PDR "geschlossen" wurde, dann hat Alaska ja die Arbeit geleistet, warum wird das dann nicht den Xbase++ Usern (umgehend) mitgeteilt ?
wäre das nicht eine erfreuliche Nachricht wenn man das in der (geschlossenen) Newsgroup liest ?!

Optimal wäre ein "Frank++" der sich "täglich" um den "BUG Demo" Bereich kümmert und das "BUG Demo" ausprobiert ...
Damit wäre auch das Thema "Upload" oder "Runtime" erledigt da es immer für alle User des "geschlossenen" Bereich gilt.

Ich denke das dieser "Service" wie eine "Subscription" zu werten wäre und ich bereit bin einen Obolus dafür "zu zahlen".

Dies wäre also meine Frage an Alaska ob so was (umgehend) umgesetzt werden könnte, damit Alaska wieder den "Kontakt"
zu seinen Usern herstellt, um sich "um deren" Probleme zu kümmern die hier und heute anliegen.

[Manfred]

Stimme ich Dir erstmal so zu.

[Tom]

Mmh. Meiner Meinung nach gibt es diesen Service bereits. Er nennt sich "Support". Man schickt eine Mail mit einem Beispiel und bekommt dann Antwort von denen. Wenn es um einen nachstellbaren Fehler ging, wird der in einen PDR überführt. Auch das wird dem Meldenden mitgeteilt. Den PDR kann man dann bookmarken und regelmäßig nachschauen, ob und wann er geschlossen wurde. Es hat m.E. wenig Sinn, dann auch noch über den Stand zu informieren, weil damit sofort das Argument verbunden wäre, man müsste ja alle informieren, die diesen Fehler haben, was einen enormen Aufwand generieren würde. Außerdem weiß man das schlicht nicht. Compilersupport ist auch eine Holschuld.

Und, nicht vergessen: Wir sind keine "User". User sind die Leute, die unsere Applikationen benutzen. Wir sind Entwickler. Und das bedeutet, dass jeder von uns in sehr komplexer Weise völlig anders mit dem Produkt umgeht. Fälle, wie sie unser Support kennt ("Wenn ich auf diese Schaltfläche drücke, kommt überhaupt nichts, aber mein Telefon klingelt"), gibt es für den Hersteller eines Compilers nicht. Wir setzen 3rd-Party-Produkte ein, zig Betriebssystemversionen, chaotische Netzwerke und weiß der Geier was noch alles.

[Manfred]

Wie wir sehen, ist alles gar nicht so einfach.


(besonders wenn man es doppelt nimmt)

[AUGE_OHR]

Mmh. Meiner Meinung nach gibt es diesen Service bereits. Er nennt sich "Support".

mein Vorschlag basiert eher auf dem Forum Gedanke und ist "öffentlich" für die registierten Xbase++ User gedacht.

Was soll das Geheimnis Getue, wem ist damit gedient ? Informationen sollten allen dienen so wie es hier auch im Forum ist.

Auch denke ich das es eher eine Art "Puffer" zwischen User Problemen und Support sein könnte, den der "pre-Test"
könnte ja von den Usern gemacht werden womit auch die Priorität "gemessen" werden könnte.

wenn man nun wirklich soweit ist das man ein fertiges Demo hat "würde" ich es hier in das Forum stellen wollen um zu erfahren ob es nur bei meinem PC´s so ist.
Wenn Alaska nun diese Möglichkeit uns stellen würde, gäbe es ja auch keine Copyright Probleme wenn andere Xbase++ User es in "ihrer" Umgebung testen.

Ich habe ja "mein" chinesisch Problem mit Xbase++, wer hier im Forum könnte das auf einem chinesischen OS() testen ?
In einem (englischen) Alaska Forum hätte ich vielleicht eine Chance zumindest ein "confirm" zu bekommen ...

Compilersupport ist auch eine Holschuld.

mag sein wenn man damit Geld verdient, ansonsten muss man selbst beim "Kunden" nach harken ob was für "ihn" tun kann

Und, nicht vergessen: Wir sind keine "User". User sind die Leute, die unsere Applikationen

Ich sehe es als "Käufer" einer Ware die es benutzen, also sind wir die "User" von Xbase+ und Alaska der Hersteller.

[Jan]

Um zum eigentlichen Threadthema zurückzukommen: Meine allererste Frage an Alaska wäre: Wann kommt Unicode-Unterstützung? Und UTF-8?

Jan

[Markus Walter]

Hallo,

ich möchte mal wieder (auch schon per mail an den Alaska-Support) die versprochene Aktualisierung der OP-Lock/Registry-Schalter-Geschichte für moderne Betriebssysteme anmahnen.

[Armin]

Aus der WAA-Ecke:

- WAA mit Dateiupload
- WAA mit MS-Excel-Ansteuerung
- Einfache Möglichkeit mehrere WAA-Server zu starten und Prozesse zu verteilen (Socket-Error-Problem...)

Gruß, Armin

[brandelh]

Hi,

das normale Windows List View Control als XbpListView()
das Kalender Control (wie im Beispiel) mit der Möglichkeit Feiertage BOLD zu machen ...

[Manfred]

Z.B.

wenn seit 2007 bekannt ist, dass der Indexkey keine 512 Zeichen lang sein darf, dies aber immer noch in der Anleitung so steht. Und das auch noch blau unterlegt, was doch m.W. bedeuten soll, es wurde aktualisiert seit der letzten Version.

[brandelh]

Hi,

der XppFD ist wegen einiger Probleme nicht soo brauchbar (kein UNDO, beim Anklicken wird oft die Position verschoben etc.)
aber zum kurz mal so eben ... die nötigen Controls in etwa einzustellen, ganz nett ...
Im Class Code werden dann ja auch 2 Dateien erzeugt,ABER (zumindest) eines fehlt !!!

In der INIT wird Position und Größe fix hinterlegt ...
aber erst nach ::super:create kann man mit diese per SetPos() wieder ändern ... das kostet ZEIT und ist unnötig.

BESSER wäre es, wenn beide als Instanzvariablen verfügbar wären, dann könnte man in der eigenen INIT ... oder vor CREATE noch umsortieren ...

Code: Alles auswählen

oSLE:aCurPos := { nZeile, nSpalte }
oSLE:aCurSize := { nHeigth, nWidth }
oSLE:create()

Vermutlich sind diese intern vorhanden, man müsste diese nur Zugänglich machen ...

[AUGE_OHR]

wenn seit 2007 bekannt ist, dass der Indexkey keine 512 Zeichen lang sein darf

... und der Status immer noch "open" ist dann wird es Zeit das da mal was passiert.

Auch M$ hat mal eine Zeit lang "primär" BUGfix erledigt statt neue zu produzieren ...

Forderung : Es sollten alle "open" PDR neu "bewertet" werden um die endlich "abzuarbeiten"

... von genau sowas, "voting" genannt, sprach doch mal der CEO von Alaska ... wann werden Ver"sprechen" denn eingelöst ?

[Jan]

Steffen hat mal (war das in Berlin zum XUG-Treffen 2006?) gesagt, Xbase++ wäre bereit für 64 Bit. Müßte nur noch ein Compilerschalter umgelegt werden. Da mit Windows 7 sehr viele Kunden auf 64 Bit umsteigen: Wäre es dann nicht an der Zeit, das dann auch rauszugeben?

Jan

[Manfred]

vielleicht klemmt ja der Schalter? Oder ist korrodiert, weil er noch nicht benutzt wurde.

[Sören]

Hallo Tom,

danke für Deine Fragen-Sammel-Initiative!

Meine Fragen an Alaska sind:

(1)
Ist es noch in Planung, Xbase++-DLL's für andere (nicht Xbase++-Programme) nutzbar zu machen?

(2)
Jan erwähnte es bereits: Wie steht's mit einem 64-Bit Xbase++ ?

(3)
Wird die max. Dateigröße bei DBFDBE (aktuell 2,4GB) und bei FOXDBE (aktuell 2GB) zukünftig erhöht oder die Größenbeschränkung ganz aufgehoben?
Was ist mit der Memofile-Größe bei FOXDBE (aktuell auf 2GB limitiert), während die Größe bei DBFDBE-Memofiles unlimitiert ist?
Die Dateigrößen für CDXDBE bzw. NTXDBE müssten dann wohl auch entsprechend angepasst werden, wobei CDXDBE aktuell auf 2GB limitiert ist und für die NTXDBE 4GB!!! eingestellt werden können (also fast die doppelte Größe einer DBF).
Anmerkung: Falls sich mit dem SL1 (den ich nicht habe) in dieser Hinsicht schon etwas getan haben sollte, bitte ich die Frage auszulassen!

[AUGE_OHR]

hi,

ich wollte mal fragen was nun mit der Umfrage weiter geschieht ?

[Tom]

Hallo, Jimmy.

Ich schließe den Thread dieser Tage (ich denke, bis zum Ende der Woche kann ich ihn noch offenlassen) und "bewerbe" mich parallel um einen Telefontermin. Sobald der dann steht, fasse ich die Fragen nochmal zusammen, stelle die entstehende Liste kurz zur Diskussion und trage sie anschließend Steffen vor. Die Ergebnisse kommen dann ans Ende dieses Threads.

[UliTs]

Hallo Tom,

mich würde sehr ein neuer Browser interessieren: leistungsfähig und trotzdem schnell.

Uli

[Manfred]

also die eierlegende Wollmilchsau