Excel als Browser

[P. Jossi]

Die Anwender meiner Software sind nun langsam alle definitiv jünger als ich.
Immer wieder wird ein Browser ala Excel gewünscht. Daher kommt die idee Excel als Browser zu verwenden. Mich interessiert wie Ihr das sieht und ob jemand sowas realisiert hat.

das beispiel xppw32\source\samples\activex\msexcel\excel2
läuft auf allen meiner Rechnern (3 Stück notbook und desktops) extrem langsam. Eine Sekretärin würde das schneller eintippen.
Virusscaner ist ab geschaltet. Das gleiche Beispiel läuft aber auf anderen Rechnern ok, Wer hat eine idee woran das liegen könnte,
Liebe Grüsse aus der Schweiz Peter.

[Koverhage]

Peter,

was genau machst Du? Excel sollte grundsätzlich unsichtbar sein, solange wie die Daten aufbereitet werden.

[Tom]

Hallo, Peter.

Die ActiveX-Komponente von Excel kann u.U. sehr langsam sein, das hängt von der Office-Version und - meiner Beobachtung nach - von der Hardwareausstattung des Rechners ab. Mit normalen XbpBrowses oder sogar XbpQuickbrowses vergleichbare Geschwindigkeiten wirst Du auf diese Art aber nie erreichen.

Ich frage mich allerdings, was Du zu machen versuchst. Ein "Browser á la Excel" ist nach meiner Lesart eine "Tabelle, die wie Excel aussieht". Das ist in Näherung mit Bordmitteln zu erreichen. Die Frage, die sich mir in erster Linie stellt, ist aber: Was willst Du browsen? Und mit welcher Funktionalität? Es ist nicht ganz ungefährlich, DBF-Tabellen mit Excel zu browsen, da die Tabellenstruktur beim Speichern verschüttgehen kann.

[P. Jossi]

vielen Dank für die Antworten

Ich denke nicht dass die Hardware auf allen 3 so verschiedenen PC genau das gleiche verhalten verursacht.
Eher logisch wäre dass meine Office version klemmt.

Könnten Einstellungen im ODBC Datenquellen dafür verantwortlich sein?

Nun was will ich machen.

Die jungen sind nund mal auf Excel eingeschossen

die wollen Zeilen dazwischen schieben, Zeilenhöhen ändern, individuelle Farben einstellen, Spalten ausblenden, ersetzen von Werten mit einer Formel etc, einfach den wahnsinns Konfort den Excel bietet.
in Xbase würde ich das in 5 Jahren nicht hinkriegen (mit oder ohne Express)

Eben weil ich weiss dass da viele Pferdefüsse autauchen werden habe ich die Frage gestellt
Peter

[Tom]

Hallo, Peter.

Es gibt einen m.E. entscheidenden Pferdefuß: Du übergibst die Kontrolle komplett an Excel. Nichts mehr mit Validierung, keine Konsistenzprüfung, keine automatische Aktualisierung von Indexen, keine Unterstützung von Memofeldern, keine Unterdrückung von gelöschten Datensätzen, und zu allem Überfluß möglicher Verlust der ursprünglichen Datenstruktur. Das Browsen und Manipulieren von DBF-Tabellen mit Excel (außerhalb der eigentlichen Applikation) war bei uns, bis wir die Daten teilweise verschlüsselt haben, eine häufige Fehlerursache.

Ich halte Deinen Ansatz für falsch. Deine Leute wollen gerne mit Excel arbeiten, Spalten einfügen, Zeilen einfügen, Zellen einfärben, Spaltenbreiten verändern? Mit Verlaub, da brauchst Du keine fünf Jahre für, um das mit Xbase++ zu erreichen, aber Du bräuchtest mehr als zehn Jahre, um den Scheiß, den Deine Anwender mit Excel in die Datenbank importieren, wieder geradezubiegen.

Spaltenbreiten merken sich DCBROWSES, wenn man DC_AutoRestoreBrowse() benutzt. Wenn das DCBROWSE die OPTIMIZE-Klausel hat, führt ein Doppelklick zwischen die Header zur "Optimierung" der Spaltenbreite, wie bei Excel. Zellen kann man mit wenigen Hilfsmitteln dazu bringen, sich wunschgemäß einzufärben, allerdings benötigt man dazu Datenbankfelder (oder irgendwelche MemVars), die sich die Farben merken - alles andere läßt sich über den COLORBLOCK der DCBROWSECOL managen. Spalten einfügen? Schau Dir mal die Samples von eXpress++ an, aber denk daran, daß jede eingefügte Spalte auch ein eingefügtes Feld nach sich ziehen muß. Und eine neue Zeile erzeugt man im Zweifelsfall mit DbAppend(). Wenn der Index richtig sitzt, entsteht sie - ein bißchen Code eingebaut - auch an der Stelle, wo gerade "Ins" gedrückt wurde.

[Koverhage]

Hallo Tom,

nur das DC_AutoRestoreBrowse() nicht so funktioniert wie es sollte.

Klaus

[Tom]

Hallo, Klaus.

DC_AutoRestoreBrowse() hat immer dann Probleme, wenn Browses mit gleicher ID von Fall zu Fall mit unterschiedlichen Spalten bestückt werden, zum Beispiel so:

Code: Alles auswählen

@ 1,1 DCBROWSE oBrowse ALIAS "data" ... ID "mybrowse"
DCBROWSECOL FIELD data->name ...
IF lMyOption1
  DCBROWSECOL ...
ENDIF

Durch "lMyOption1" erzeuge ich zwei unterschiedliche Browses, und das muß ich berücksichtigen, weil das DC_AutoRestoreBrowse() dann nicht mehr weiß, wo es die von Fall zu Fall auftauchende zweite Spalte hintun soll. Ich muß für diesen Fall die ID wechseln:

Code: Alles auswählen

ID "mybrowse"+IF(lMyOption1,"2","")

oder ähnlich. Ansonsten funktioniert das bei mir (Build 241) einwandfrei, außer bei Browses, die auf Tabpages sitzen, die per DC_MergeGetLists erst später einem existenten Dialog zugefügt werden.

[brandelh]

Hi,

ich vermute dass Peters Anwender ein ListView-Control meinen, wie im Explorer etc. verbaut.
Das ist ein common control, das einem Browser sehr ähnlich sieht, aber alles mögliche kann (drag / drop von Spalten) Bilder, Text, Icons in Spalten, mit und ohne Linien ...

In der Win32 SDK steht es unter common controls. Also ein DLL Aufruf, wobei ich mich damit aber nicht beschäftigt habe. Ich hatte sowas schon mal gesehen und wurde in einer Entwicklungsumgebung fündig.

Im Alaska Forum (2003/2004) steht etwas über WinLib (Referenz gibt es nicht mehr) und Cockpit ... scheinbar eine Erweiterung mit der man die XbParts gegen richtige Windows Controls (auch dem ListView) austauschen kann.
Weiß da jemand mehr ?

[Martin Altmann]

Hallo Hubert,
nun - auch auf die Gefahr hin, vom eigentlichen Thema abzuweichen: Cockpit war Thema auf der letzten DevCon und Michael hat wirklich einen guten Job gemacht!!
Lade Dir mal einfach die Demo herunter und schau sie Dir in Ruhe an.

Viele Grüße,
Martin