Seite 1 von 1

Vorsicht mit v1.9.331 & Excel unter Win98se !!!

Verfasst: Mi, 31. Mai 2006 12:19
von AUGE_OHR
hi,

Vorsicht wenn jemand unter Win98se Excel mit ActiveX ansprechen will.
wie in der "beta v1.9.318" bleibt Excel im Speicher (trotz oExcel:destroy)
bis die ganze Application geschlossen wird.
merkt man das nicht und ruft die Function nochmals auf so kommt es
zum Absturz.

... hoffe das Alaska schnell den "bekannten" BUG behebt ...

gruss by OHR
Jimmy

Verfasst: Mi, 31. Mai 2006 12:30
von Tom
Hallo, Jimmy.
... hoffe das Alaska schnell den "bekannten" BUG behebt ...
Wenn Du es meldest. 8)

Verfasst: Mi, 31. Mai 2006 12:41
von AUGE_OHR
hi,
Tom hat geschrieben:Hallo, Jimmy.
... hoffe das Alaska schnell den "bekannten" BUG behebt ...
Wenn Du es meldest. 8)
jup, hab ich gestern als ich es gemerkt habe gleich gemeldet und
es auch in die NG Bugreport geschrieben ...

dumm ist nur das ich auch das nicht in der letzten RC 1.9.330 gemerkt
habe ... wer kommt schon darauf das "behobene" Probleme wieder
auftauchen ... :(

gruss by OHR
Jimmy

Verfasst: Mi, 31. Mai 2006 13:56
von andreas
Hallo Leute,

ich kenne das Poblem nich nur von Win98. Zu so einem zustand kommt es auch ab und zu, wenn Excel ganz normal gestartet und beendet wird. Danach kann der nicht mehr gestartet werden, bis der Prozess mit Taskmanager abgeschossen wird. Dann gehts wieder.
Das gleiche Problem habe ich aber auch schon mit anderen Programmen unter Windows 2000/XP erlebt.

Verfasst: Mi, 31. Mai 2006 14:08
von brandelh
Hallo Andreas,

meinst du mit 'ganz normal gestartet', dass es nicht am Xbase++ bzw. ActiveX liegt, sondern dass Excel nach einigen Starts nicht wieder sauber beendet wird ? Und dies auch ohne ActiveX ?

Verfasst: Do, 01. Jun 2006 9:15
von andreas
Hallo Hubert,
meinst du mit 'ganz normal gestartet', dass es nicht am Xbase++ bzw. ActiveX liegt, sondern dass Excel nach einigen Starts nicht wieder sauber beendet wird ? Und dies auch ohne ActiveX ?
genau das meine ich. Das gleiche kam auch noch bei älteren R&R-Versionen bei dem Reportdesigner. Bei der neuen Version habe ich es noch nicht gehabt.

Verfasst: Do, 01. Jun 2006 9:28
von brandelh
Na wenn das so ist, liegt doch der Fehler bei M$ Excel und nicht bei Xbase++ ActiveX oder ?

Verfasst: Do, 01. Jun 2006 12:53
von andreas
Na wenn das so ist, liegt doch der Fehler bei M$ Excel und nicht bei Xbase++ ActiveX oder ?
Oder an irgendwelchen Standardroutinen von Windows, die für das Beenden der Programme und Speicherbereinigung verantwortlich sind.

Verfasst: So, 11. Jun 2006 23:42
von AUGE_OHR
hi,
brandelh hat geschrieben:Na wenn das so ist, liegt doch der Fehler bei M$ Excel und nicht bei Xbase++ ActiveX oder ?
also damit es jeder (der noch Win98se) hat ausprobieren kann :

C:\ALASKA\XPPW32\SOURCE\samples\activex\msexcel\excel1.exe
starten und bis zum WAIT. dann Crtl-Alt-Del und in den Taskmanager
nachsehen. Dort ist dann Excel1.exe UND Excel.exe im Taskmanager
zu sehen.

wer das "nachvollziehen" kann möge doch bitte ein Msg an Alaska
schicken ... bei mir wird es langsam "dringend" (31.06.06)

danke, gruss by OHR
Jimmy

Verfasst: Mi, 14. Jun 2006 14:54
von Tom
Ich bin gerade dabei, sämtliche AX-Controls von JazzAge auf die XbpActivexControl-Klasse umzustellen. Wir benutzen u.a. TX TextControl. Um auszuprobieren, wie die Umstellung am günstigsten funktioniert, habe ich einen kleinen Wordprocessor geschrieben. Ein Static enthält die vier Controls, aus denen TX besteht (das Control selbst, ein Ruler, ein Statusbar und eine Buttonbar). Funzt auch ganz super (und ist sehr viel schneller als JazzAge). ABER: Obwohl ich die Objekte destroye, die Vars NIL setze und vieles andere mehr, bleibt ein Prozeß mit dem Namen der Testapplikation (TXTEST) hängen, die Applikation ist unter "Anwendungen" allerdings nicht mehr zu sehen. Nun staune ich. :D

Verfasst: Mi, 14. Jun 2006 15:28
von Martin Altmann
Hallo Tom,
kann das was damit zu tun haben, dass das ActiveX-Control nicht "Thread-safe" ist und Du es in einem einzelnen Thread startest?
So etwas wurde ja auf der DevCon erwähnt...

Viele Grüße,
Martin

Verfasst: Mi, 14. Jun 2006 15:48
von Tom
Hallo, Martin.

Nein, das isses nicht. Es gibt zwei Instanzvariablen, die man bestücken kann, wenn ein AX-Objekt Probleme bereitet.

Code: Alles auswählen

oActivexObject:USEREVENTS := .F.
sorgt dafür, daß alle Events innerhalb eines Threads verbleiben und

Code: Alles auswählen

oActivexObject:USEGUITHREAD := .F.
hindert das Objekt daran, mit dem EVM (Event Manager) zu interagieren. Letzteres führt bei meinem Textverarbeitungsbeispiel dazu, daß die ganze Anwendung steht und nicht mehr auf Events reagiert.

Irgendwie und irgendwo wird die Verbindung zum Objekt nicht gelöst. Bei JazzAge gab es - im Anschluß an die Erzeugung des AX-Objektes - noch explizite Methoden :Connect und :Disconnect, und irgendwas fehlt (mir) da jetzt. :?

Verfasst: Mo, 19. Jun 2006 14:35
von andreas
Hallo Jimmy,

ich habe mein kleines Testprogramm gefunden, wo ich mit ActivX und Excel rumprobiert habe. Unter WinXP habe ich mehrmahls hintereinander ausgeführt und keine Probleme gehabt.

Code: Alles auswählen

#INCLUDE "activex.CH"
#pragma library("ascom10.LIB")

PROCEDURE Main
	oApp := CreateObject( "Excel.Application" )

	IF NIL == oApp
		// Word.Application could not be created.
		? "Error: ", ComLastError()
		? "Description:"
		? ComLastMessage()
		RETURN
	ENDIF

	// Access a property of the Word application
	? oApp:visible
	// Assign a value to a property
	oApp:visible := ! oApp:visible

	*oApp:cells(1,1):="Test"
	oApp:Workbooks():Add()                       //Mappe einfügen
	oApp:Sheets():Add()                          //in der Geöffneten Mappe eine neue Tabelle einfügen
	oApp:WorkSheets():Add()                      //in der Geöffneten Mappe eine neue Tabelle einfügen
	**oApp:Workbooks():Open("C:\MyFolder\MyBook.xls") //Öffnen einer Mappe
	oApp:Worksheets("Tabelle1"):select()         //Auswählen einer Tabelle in der geöffneten Mappe

	oApp:Range("A2"):Value := "Test"             //zuweisen eines Wertes in eine Zelle der aktiven Tabelle

	FOR i := 1 TO 5
		oApp:Cells(1,i):value := i
	NEXT

	oApp:Worksheets("Tabelle2"):select()         //Auswählen einer Tabelle in der geöffneten Mappe

	oApp:Range("A1"):Value := "Nr"               //zuweisen eines Wertes in eine Zelle der aktiven Tabelle
	oApp:Range("A1"):Font():Size := 14           //Schriftgrösse ändern
	oApp:Range("A1"):Font():Name := "Times"      //Schrift festlegen
	oApp:Range("A1"):Font():Bold := .t.
	oApp:Range("B1"):Value := "Wert"             //zuweisen eines Wertes in eine Zelle der aktiven Tabelle
	oApp:Range("B1"):Font():Size := 14           //Schriftgrösse ändern
	oApp:Range("B1"):Font():Name := "Times"      //Schrift festlegen
	oApp:Range("B1"):Font():Bold := .t.
	FOR i := 1 TO 5
		oApp:Cells(i+1,1):value := i
		oApp:Cells(i+1,2):value := i*1000/(i+1)
		*oApp:Cells(i+1,1):Font():Size := 12 + i
		oApp:Cells(i+1,2):NumberFormat = "#.##0,00" //Format für Nummerische Werte festlegen
		IF (i%2)==0
			oApp:Cells(i+1,2):Font():Bold := .t.   //Fett-Schrift in der Zelle einschalten
		ENDIF
	NEXT
	*oApp:Range("A3"):Formula := "=A1+B1"        //eine Formula in der Zelle speichern
	oApp:Range("B7"):Formula := "=summe(B2:B6)"  //eine Formula in der Zelle speichern
	oApp:Range("B7"):Font():Size := 12           //Schriftgrösse ändern
	oApp:Range("B7"):Font():Name := "Arial"      //Schrift festlegen
	oApp:Range("B7"):Font():Bold := .t.
	oApp:Range("A8"):Value := "asjkhdjksahdkjlsahdljsahdsaljdsamcnvnsd"
	oApp:Range("A8:C8"):MergeCells := .t.        //Zellen verbinden
	oApp:Range("A9:C9"):Merge()                  //Zellen verbinden
	wait

	*msgbox(var2char(oApp:Range("A8"):Name))

	oApp:quit()                                  //Excel beenden
	oApp:destroy()

RETURN

Verfasst: Mo, 19. Jun 2006 15:21
von Jan
Andreas,

Jimmy hat das ja auch explizit auf 98SE bezogen. Ich kann mich erinnern daß er irgendwo mal erwähnte, daß 2000 und XP keine Probleme machen.

Jan

Verfasst: Mo, 19. Jun 2006 15:25
von andreas
Hallo Jan,
Jimmy hat das ja auch explizit auf 98SE bezogen. Ich kann mich erinnern daß er irgendwo mal erwähnte, daß 2000 und XP keine Probleme machen.
ich weiss es. Ich dachte, dass vielleicht mein Code beim Testen was bringen würde. Ich kann leider den unter Win98 nicht testen, da ich keinen PC damit mehr habe.

Verfasst: Mo, 19. Jun 2006 15:32
von Jan
Wer hat schon noch so einen? :-) Ich habe meinen letzte mit Win 98 letztes Jahr im April ausgemustert. Zu viele Programme laufen halt nur noch unter 2000 oder höher.

Jan

Verfasst: Mo, 03. Jul 2006 22:22
von AUGE_OHR
Antwort von Till
ich habe den Eindruck, dass Excel unter Umständen sensibel
reagiert, wenn das Anwendungsobject vernichtet wird (oExcel)
aber noch Referenzen zu abhängigen Objekten bestehen.

Wenn Du z.B. das EXCEL1-Beispiel so abänderst, dass das
Programm so verlassen wird:

(...)
oBook := NIL
WAIT // Bisschen warten hier

oExcel:Quit()
oExcel:Destroy()

WAIT
(...)

Ist Excel beim 2.ten WAIT bei Dir dann immer noch im
Speicher? Auf meinem Rechner scheint das einen Unterschied
zu machen.
... bei mir hat es nichts gebracht

gruss by OHR
Jimmy

Verfasst: Mo, 10. Jul 2006 20:48
von AUGE_OHR
so die letzte Msg von Alaska-Software :
Andreas Herdt hat geschrieben: Leider läßt es sich im Moment nicht vermeiden, dass ungewollt noch
Instanzen von Excel im Speicher rumhängen.

Ich habe mir das im Detail mal angesehen. Fakt ist: Selbst wenn alle
verweise (Referenzen) weggeräumt werden (release/destroy) steht
Excel noch im Speicher. Einen Fix/Workaround kann ich leider
nicht bieten. Dieser würde dafür sorge tragen, dass bei einem Aufruf
von :destroy() alle Objekte von Excel ebenfalls eine :destroy() Nachricht
erhalten.
tja ... wird wohl nichts mehr mit W98se/Excel 97 ...

gruss by OHR
Jimmy

Re: Vorsicht mit v1.9.331 & Excel unter Win98se !!!

Verfasst: Mi, 07. Jan 2009 15:09
von Christof
Hallo,

das Thema ist zwar schon etwas älter, aber ich kämpfe gerade auch damit.
Gibt es denn zwischenzeitlich einen Tipp, wie man am besten vorgeht?
Ich hab's jetzt hier mit Excel 2007 unter WindowsXP zu tun.

Ich krieg' Excel.EXE einfach nicht raus aus dem Task-Manager. Erst, wenn das XBase-Programm beendet wird.

Schei....

Danke und Gruß

Christof

Re: Vorsicht mit v1.9.331 & Excel unter Win98se !!!

Verfasst: Do, 08. Jan 2009 14:10
von Lewi
Nachdem ich ein wenig experementiert habe, bin ich zu folgenden Ergebnissen gekommen:

Auf Basis folgenden Codes wird Exel aus dem Taskmanager entfernt, wenn nach ::oExcel:Quit() die Applikation mittels sleep() in einen "Wartemodus" geschickt wird:

Code: Alles auswählen

#include "activex.ch"
#include "excel.ch"

//////////////////////////////////////////////////////////////////////
// Main()-Prozedur der Anwendung
//////////////////////////////////////////////////////////////////////
PROCEDURE main
  LOCAL oExcel, oBook, oSheet
  LOCAL cSDir, cTDir
   local l, c, b, a
  // Erzeugen eines "Excel.Application"-Objektes
  oExcel := CreateObject("Excel.Application")
  IF Empty( oExcel )
    MsgBox( "Excel ist nicht installiert" )
    RETURN
  ENDIF

  // Vermeiden von Nachrichten wie "Die Datei
  // existiert bereits". Sicherstellen, dass
  // die Excel-Anwendung sichtbar ist.
  oExcel:DisplayAlerts := .F.
  oExcel:visible       := .T.

  // Das Quellverzeichnis ist das Verzeichnis mit
  // den DBF-Tabellen der Xbase++-Beispielkollektion.
  // Das Zielverzeichnis ist das Verzeichnis der
  // Anwendung.
  cTDir  := CurDrive()+":\"+CurDir()
  cSDir  := cTDir + "\..\..\data"

  // Eine DBF-Tabelle in einem Workbook oeffnen.
   oBook:= oExcel:workbooks:Open(cSDir+"\customer.dbf")


  // Das Workbook wird mit einem neuen Namen abgespeichert.
  // Ein voll qualifizierter Pfad muss angegeben werden.
  // xlWorkbookNormal erzeugt eine normale Excel-Datei.

    oBook:SaveAs( cTDir+"\MyExcel.xls" , xlWorkbookNormal )
    oBook:close()
    oBook:destroy()
    oBook := NIL
    oExcel:Quit()
    sleep(300)  // Warte 3 Sekunden ....
    oExcel:Destroy()
    oExcel := NIL
    Msgbox("Ende Excel ")  // Ein Blick auf den Blick auf den Taskmanager sollte ergeben, dass Excel.exe beendet wurde
RETURN
Der Grund liegt wohl darin, das xBase über oExcel:Destroy() die Referenz zum ActiveX-Object intern nicht auflösen kann, solange sich Excel immer noch im Speicher befindet. Ohne ein Sleep() wird zwar das Object oExcel scheinbar terminiert und expliziet auf NIL gesetzt, aber es besteht wohl weiterhin eine Speichereferenz zwischen der eigenen Anwendung und Excel. Diese Referenz wird betriebssystemseitig dann als Folge dessen erst dann aufgelöst werden, wenn die eigene Anwendung geschlossen wird.

Mit einem Sleep( nHundertelsterSec) konnte ich das Problem bisher lösen. Alternativ bietete sich die Möglichkeit an, Excel-ActiveX-Einbindungen in separate EXE-Dateien auszulagen, die mit entsprechenden Parameter aufgerufen werden. Mit Beendigung der "externen" Anwendungen wird dann grundsätzlich auch Excel aus dem Speicher entfernt.

Re: Vorsicht mit v1.9.331 & Excel unter Win98se !!!

Verfasst: Fr, 30. Jan 2009 12:17
von brandelh
Hi,

auch ich habe mich damit jetzt rumgeschlagen (XP - Excel 2003) , wobei die Ergebnisse mit 1.90.331 und 1.90.350 in Bezug auf Excel Ende recht seltsam sind. Zuerst dachte ich mit dem SL1 wäre es besser (erster Programmlauf nach kompilieren ...) aber danach blieb es meist im Speicher. Nachdem ich dann mit der 1.90.331 neu compiliert habe, trat der Fehler beim anschließenden Start auch nicht auf. Dafür aber bei den weiteren. Selbst mit Olafs Änderung ist das excel-Ende nicht sicher - allerdings ist das für die aktuelle Anwendung (Datenkonvertieren im Batchlauf) nicht wichtig.

Bei diesen Tests viel mir aber auf, dass die 1.90.331 EXE sich bei über 60 MB einpendelt und danach bestenfalls auf 50 MB runter geht. Mit dem SL1 ist das Speicherverhalten deutlich besser ! Zwar wird kurzfristig auch über 60 MB benötigt, aber schon kurz danach geht der Speicher sofort runter, im Schnitt (je nach XLS-Dateigröße) pendelt er sich bei 20 MB ein.

Das ist ein Hinweis darauf, was Alaska mit "im Unterbau schrauben" meinte :D =D> =D> =D>

Re: Vorsicht mit v1.9.331 & Excel unter Win98se !!!

Verfasst: Fr, 30. Jan 2009 12:41
von Lewi
Mann könnte das Problem generell auch über auf einen anderen Weg lösen: der Prozessliste.
In einem ähnlichen Fall mit einer ActiveX-Komponete hatte auch das Problem, dass die Anwendung nach dem Beenden hin und wieder im Speicher verblieb und nur im Taskmananger sichtbar war. Über API-Funktionen wird nun die Prozessliste durchgegangen und es werden alle entsprechenden Prozesse terminiert.

Gruß, Olaf

Re: Vorsicht mit v1.9.331 & Excel unter Win98se !!!

Verfasst: Fr, 30. Jan 2009 13:31
von brandelh
Hallo Lewi,

darf das ein Programm, das von einem (Haupt-)benutzer ausgeführt wird ?

Du hattest mal die Idee es mit einem anderen Thread bzw. einer anderen Exe zu versuchen, hat das was gebracht ?

Re: Vorsicht mit v1.9.331 & Excel unter Win98se !!!

Verfasst: Fr, 30. Jan 2009 13:54
von Lewi
darf das ein Programm, das von einem (Haupt-)benutzer ausgeführt wird ?
Für diese Frage gibt es keine generelle Antwort. Wenn ich recht erinnere, hat Word 2000 (oder eine Version davor) für jedes Dokument einen eigenen Task generiert, danach nicht mehr. Mittlerweile wird Winword auch gestartet, wenn Outlook aktiviert wird und Word zur Generierung von HTML-Dokumenten herangezogen wird. Wird in letzteren Fall Winword über den Taskmanager teminiert, hat es aber keine Folgen für Outlook - außer es wird gerade eine Mail erfasst - .

Neben Winword können auch andere Anwendungen mehrere Task erzeugen (die sich auf der Taskleiste wiederfinden), aber in der Prozessliste wiederum ist nur eine Programm-Instanz vorhanden. In sochen Fällen kann für die Terminierung nicht allein die Prozessliste herangezogen werden. Zusätzlich sollte festgestellt werden, ob sich ein entsprechender Task in der Taskleiste befindet.
Du hattest mal die Idee es mit einem anderen Thread bzw. einer anderen Exe zu versuchen, hat das was gebracht ?
Das Problem der Terminierung eines nicht aktiven Taskes bezüglich einer ActiveX-Komponente eines Dritt-Herstellers habe ich für meinen Fall gelöst.