Neue xBase++ Subskriptionen

Sonstiges (nicht kategorisierbar)

Moderator: Moderatoren

Was haltet Ihr von der neuen Update-Struktur

Super!
1
7%
Besser als vorher mit DSP-Punkten
1
7%
Egal, ich kaufe erstmal keine Updates
4
29%
Man kauft die Katze im Sack, wer weiß, ob es Alaska schafft, zumindest vierteljährlich Updates & Korrekturen zu veröffentlichen
5
36%
Hauptsache Alaska überlebt!
3
21%
 
Insgesamt abgegebene Stimmen: 14

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Beitrag von Jan »

Hallo Markus,
Die versprochene Info (von Steffen in Berlin angekündigt) an die bestehenden Subscriber ist bei mir bis heute nicht eingegangen
Genau das ist der Grund, warum auch ich mich noch nicht gekümmert habe. Denn als "alter User" mit noch 3 offenen Lieferungen sollte ich ja eigentlich einen Laufzeitbonus bekommen, lt. Aussage von Steffen. Und da habe ich noch garnichts drüber gelesen. Weder allgemein auf irgendeiner Homepage von Alaska, hier im Forum oder sonstwo, noch eine Mail, noch ein Schreiben.

Die Jungs von Alaska sind im Moment anscheinend zur Zeit dermaßen überlastet, daß die das einfach nicht auf die Reihe bekommen. Schade eigentlich, denn auch soetwas wäre Kundenpflege, die Kunden zufrieden und bei der Stange hält. Es wäre in der Tat an der Zeit, da mal Druck zu machen.

Die könnten übrigens auch an mir etwas verdienen. Denn irgendwann muß ja schließlich auch mein Bonus bei denen auslaufen. Und ich muß denen Geld für die neue Subscription überweisen. Aber wenn die ohne meine Geld klarkommen ... mein Konto freut sich.

Aber das gehört vermutlich wiederum in die Kategorie: Schöne Planung, mangelhafte Umsetzung.

Jan
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Beitrag von Manfred »

Hi,

ich habe auch noch keine Info und finde das alles sehr sehr merkwürdig.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Beitrag von AUGE_OHR »

hi,
Markus Walter hat geschrieben: hatte jetzt zum ersten Mal den Fall, dass von Alaska eine Supportanfrage abgelehnt wurde, da meine Subscription abgelaufen ist. Nun soll ich eine neue Foundation mit Support kaufen (EUR 645,- / Jahr).
Interresant wäre jetzt was du angefragt hast :
a.) einen BUG gemeldet
b.) ein Problem gehabt

wenn du a.) mit einem sample zu Alaska geschickt hast und die dafür
eine Subscription haben wollen, dann ...

bei b.) bekomme ich , trotz sample, oft keine Antwort ... aber dafür gibt
es ja auch hier das Forum :)

also her mit deinem sample, das Problem bekommt man auch ohne
Alaska in Griff (wenn es nicht a.) ist ...)

gruss by OHR
Jimmy
Benutzeravatar
Markus Walter
Programmier-Gott
Programmier-Gott
Beiträge: 1018
Registriert: Di, 24. Jan 2006 10:22
Wohnort: Saarland

Beitrag von Markus Walter »

Hallo Jimmy,

es ging (natürlich) um mein Problem mit dem Kontext-Menü im XbpHtmlViewer, respektive generell um das Thema: Reagieren auf Ereignisse, die auftreten wenn ein ActiveX-Control den Focus hat.

z. B.:
- Unterdrücken des Context-Menü beim XbpHtmlViewer
- ESC (oder sonstige Tastatur-Events) behandeln, wenn der XbpHtmlViewer den Focus hat

Habe zwischenzeitlich meine Subscription im OnlineShop verlängert (und wenn Alaska den Geldeingang verzeichnet, darf ich auch wieder Support-Anfragen stellen...)

Ich hätte auch noch den ein oder anderen Bug zu melden (teilweise wieder zu melden):

- GetUniqueFileName() erzeugt eine Datei im Temp-Verzeichnis und löscht diese nicht wieder (habe ich schon im Sommer letzten Jahres gemeldet, ist noch nicht mal als PDR angelegt)

- ich habe immer noch massive Probleme mit "Systemlast 100%" bei einigen meiner Anwender, aber da hat Alaska keine Idee, wobei man in den diversen Foren/newsgroups ja auch schon von einigen anderen Programmieren gelesen hat, die offenbar exakt die gleichen Probleme haben.
Da habe ich langsam Anwender, die richtig sauer sind!
Gruß
Markus

Mitglied der XUG Saarland-Pfalz
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Beitrag von AUGE_OHR »

Hi,
Markus Walter hat geschrieben: es ging (natürlich) um mein Problem mit dem Kontext-Menü im XbpHtmlViewer, respektive generell um das Thema: Reagieren auf Ereignisse, die auftreten wenn ein ActiveX-Control den Focus hat.

z. B.:
- Unterdrücken des Context-Menü beim XbpHtmlViewer
- ESC (oder sonstige Tastatur-Events) behandeln, wenn der XbpHtmlViewer den Focus hat
sorry vorweg : hast du dich schon mal mit einem anderen activeX
ausser den von Alaska beschätig ?
In

Code: Alles auswählen

 C:\ALASKA\XPPW32\SOURCE\SYS\axctrls.prg 

findest du ja den Source zu allen "neuen" activex Class(en).
Dort musst du ansetzten !
Markus Walter hat geschrieben: Habe zwischenzeitlich meine Subscription im OnlineShop verlängert (und wenn Alaska den Geldeingang verzeichnet, darf ich auch wieder Support-Anfragen stellen...)
Wenn das obrige deine Anfrage war kann ich es verstehen das keine
Antwort kommt ... Das muss der User lernen.

Ich glaube auch kaum das Alaska den Source jemals "aufbohren" wird
damit man damit "vernünftig" was machen kann ... eben so wie auch die
anderen Beispiele nur rundimentär sind.

Gewarnt hatte ich schon zur beta Phase von v1.9x, das die notwendigen
*.OCX M$ComClt32 etc., sich nicht unter XP Pro x64 installieren lassen
und es dabei zu Crash kommt. Unter VISTA32 scheint es zu gehen aber
unter VISTA64 ist das selbe Problem wie XP64 ... crash.
Markus Walter hat geschrieben: Ich hätte auch noch den ein oder anderen Bug zu melden (teilweise wieder zu melden):

- GetUniqueFileName() erzeugt eine Datei im Temp-Verzeichnis und löscht diese nicht wieder (habe ich schon im Sommer letzten Jahres gemeldet, ist noch nicht mal als PDR angelegt)
und wie öft pro Tag "nervst" du die damit ?
Markus Walter hat geschrieben: - ich habe immer noch massive Probleme mit "Systemlast 100%" bei einigen meiner Anwender, aber da hat Alaska keine Idee, wobei man in den diversen Foren/newsgroups ja auch schon von einigen anderen Programmieren gelesen hat, die offenbar exakt die gleichen Probleme haben.
Da habe ich langsam Anwender, die richtig sauer sind!
schon mal EventSpy angesetzt ? Damit hab ich meine Probleme gefunden
wenn ich mal wieder einen Event an das falsche Object geschickt habe.

Wenn man dann bei 100% CPU mit ALT-C abbricht findet man sich
meistens an folgendert Stelle wieder :

Code: Alles auswählen

         OTHERWISE
            oXbp:HandleEvent ( nEvent, mp1, mp2 )  // -> hier bei 100%
      ENDCASE
   ENDDO
also wenn du :Keyboard Slot oder PostAppEvent(xbeP_Keyboard,x,y,Obj)
verwendest, dann würde ich darauf wetten das es dort passiert.

Manchmal hatte ich davon "zuviel" verwendet und ebenfall 100% CPU.

Code: Alles auswählen

PROCEDURE MAIN
...
   oDlg := XbpDialog():new( AppDesktop(),, aPos, aSize, , .F.)
...
   oXbp := Xbp_xxx():new()
   AADD(aControls,oXbp)                     // control to keyhandler
...
   //
   // install keyboard handler
   //
   bKeyHandler := {|nKey,uNIL,obj| MAINKEYS(nKey, ....) }
   AEval( aControls, {|o| o:keyBoard := bKeyHandler } )
...
   DO WHILE .NOT. SP_MainExit()
      nEvent := AppEvent( @mp1, @mp2, @oXbp, nTimeout ) // nTimeout
      DO CASE
...
         //
         // do NOT Scroll2bar :keyboard here !!!
         //
*      CASE nEvent == xbeP_Keyboard .AND. mp1 == xbeK_RIGHT
*         IF oBar:getData()+1 > SP_Duration()
*            oBar:setData( SP_Duration() )
*         ELSE
*            oBar:setData( oBar:getData()+1 )
*         ENDIF
*         Scroll2bar( oBar:getData(), XBPSB_NEXTPOS ... )
*         setAppFocus(oDlg)
...
      OTHERWISE
          oXbp:handleEvent( nEvent, mp1, mp2 ) // hier 100%
      ENDCASE
man sieht also das ich jedem XbPart schon einen :Keyboard Handler
zugewiesen habe. Wenn ich in der Main darauf reagiere lande ich
irgendwann bei Otherwise ... :(

Wenn ich allerdings den :Keyboard Handler nehme funktioniert alles

Code: Alles auswählen

PROCEDURE MAINKEYS(nKey, ...)
  DO CASE
...
      CASE nKey == xbeK_RIGHT
      IF aoChild[CH_BAR]:getData()+1 > SP_Duration()
         aoChild[CH_BAR]:setData( SP_Duration() )
      ELSE
         aoChild[CH_BAR]:setData( aoChild[CH_BAR]:getData()+1 )
      ENDIF
      Scroll2bar( aoChild[CH_BAR]:getData(), XBPSB_NEXTPOS ... )
      setAppFocus(aoChild[CH_BAR])
...
wie man sehen kann ist der Code absolute identisch, aber in der Main loop
geht es eben nicht, deshalb möglist nicht die DO WHILE loop benutzen
sondern wenn möglich immer einen :Keyboard Slot benutzen.

gruss by OHR
Jimmy
Benutzeravatar
Markus Walter
Programmier-Gott
Programmier-Gott
Beiträge: 1018
Registriert: Di, 24. Jan 2006 10:22
Wohnort: Saarland

Beitrag von Markus Walter »

Hi,
AUGE_OHR hat geschrieben:Hi,
Markus Walter hat geschrieben: Ich hätte auch noch den ein oder anderen Bug zu melden (teilweise wieder zu melden):

- GetUniqueFileName() erzeugt eine Datei im Temp-Verzeichnis und löscht diese nicht wieder (habe ich schon im Sommer letzten Jahres gemeldet, ist noch nicht mal als PDR angelegt)
und wie öft pro Tag "nervst" du die damit ?
Gar nicht, ich dachte einmal melden reicht...
AUGE_OHR hat geschrieben:
Markus Walter hat geschrieben: - ich habe immer noch massive Probleme mit "Systemlast 100%" bei einigen meiner Anwender, aber da hat Alaska keine Idee, wobei man in den diversen Foren/newsgroups ja auch schon von einigen anderen Programmieren gelesen hat, die offenbar exakt die gleichen Probleme haben.
Da habe ich langsam Anwender, die richtig sauer sind!
schon mal EventSpy angesetzt ? Damit hab ich meine Probleme gefunden
wenn ich mal wieder einen Event an das falsche Object geschickt habe.

Wenn man dann bei 100% CPU mit ALT-C abbricht findet man sich
meistens an folgendert Stelle wieder :

Code: Alles auswählen

         OTHERWISE
            oXbp:HandleEvent ( nEvent, mp1, mp2 )  // -> hier bei 100%
      ENDCASE
   ENDDO
also wenn du :Keyboard Slot oder PostAppEvent(xbeP_Keyboard,x,y,Obj)
verwendest, dann würde ich darauf wetten das es dort passiert.

Manchmal hatte ich davon "zuviel" verwendet und ebenfall 100% CPU.

Code: Alles auswählen

PROCEDURE MAIN
...
   oDlg := XbpDialog():new( AppDesktop(),, aPos, aSize, , .F.)
...
   oXbp := Xbp_xxx():new()
   AADD(aControls,oXbp)                     // control to keyhandler
...
   //
   // install keyboard handler
   //
   bKeyHandler := {|nKey,uNIL,obj| MAINKEYS(nKey, ....) }
   AEval( aControls, {|o| o:keyBoard := bKeyHandler } )
...
   DO WHILE .NOT. SP_MainExit()
      nEvent := AppEvent( @mp1, @mp2, @oXbp, nTimeout ) // nTimeout
      DO CASE
...
         //
         // do NOT Scroll2bar :keyboard here !!!
         //
*      CASE nEvent == xbeP_Keyboard .AND. mp1 == xbeK_RIGHT
*         IF oBar:getData()+1 > SP_Duration()
*            oBar:setData( SP_Duration() )
*         ELSE
*            oBar:setData( oBar:getData()+1 )
*         ENDIF
*         Scroll2bar( oBar:getData(), XBPSB_NEXTPOS ... )
*         setAppFocus(oDlg)
...
      OTHERWISE
          oXbp:handleEvent( nEvent, mp1, mp2 ) // hier 100%
      ENDCASE
man sieht also das ich jedem XbPart schon einen :Keyboard Handler
zugewiesen habe. Wenn ich in der Main darauf reagiere lande ich
irgendwann bei Otherwise ... :(

Wenn ich allerdings den :Keyboard Handler nehme funktioniert alles

Code: Alles auswählen

PROCEDURE MAINKEYS(nKey, ...)
  DO CASE
...
      CASE nKey == xbeK_RIGHT
      IF aoChild[CH_BAR]:getData()+1 > SP_Duration()
         aoChild[CH_BAR]:setData( SP_Duration() )
      ELSE
         aoChild[CH_BAR]:setData( aoChild[CH_BAR]:getData()+1 )
      ENDIF
      Scroll2bar( aoChild[CH_BAR]:getData(), XBPSB_NEXTPOS ... )
      setAppFocus(aoChild[CH_BAR])
...
wie man sehen kann ist der Code absolute identisch, aber in der Main loop
geht es eben nicht, deshalb möglist nicht die DO WHILE loop benutzen
sondern wenn möglich immer einen :Keyboard Slot benutzen.

gruss by OHR
Jimmy
Ich glaube nicht, dass meine Probleme daher kommen. Ich hatte keinen solchen Fall unter 1.82 und habe meine Quellen eins zu eins mit 1.9 umgesetzt. Das Ganze ist ja auch nicht nachvollziehbar. Irgendwann tritt diese Systemlast auf an Stellen, die hunderte Male pro Tag beim Anwender benutzt werden. Manchmal tritt es 14 Tage nicht auf und dann 3x am Tag. Ich habe jetzt mal wieder einen Thread in bugreport gestartet. Man konnte ja auch schon von anderen lesen, die ähnliche Probleme mit 1.9 haben.
Gruß
Markus

Mitglied der XUG Saarland-Pfalz
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hi,

zu deinen genauen Problemen kann ich jetzt zwar nichts sagen,
aber zu deinem Eventloop habe ich 2 Anmerkungen:

1. Wenn dein nTimeOut recht klein ist, wird die Schleife und alle Abfragen häufig durchlaufen. Meist wird aber kein Event vorkommen. xbe_None sollte in solchen Fällen als erstes abgefragt werden und einfach nix machen.

2. Du fragst nEvent == xbeP_Keyboard .and. .... ab.
Wenn du mehr als eine Taste hast, ist das unnötige Arbeit !
Unnötige Arbeit muss man in der Eventloop und anderen Eventhandlern unbedingt vermeiden.

Hier mein Vorschlag für den inneren Teil :

Code: Alles auswählen

do case
     case nEvent = xbe_None  // == nur bei Strings verwenden !
           * mach nix                // meist nur diese Abfrage ... Rest gespart
     case nEvent = xbeP_Keyboard 
           do case 
                case welche Taste ...
                        Sonderbehandlung fällig ?
                        if erledigt ?
                           nEvent  := xbe_None  // blocken
                        endif
           endcase
endcase

if  nEvent <> xbe_None
    oXbp:handleEvent( nEvent, mp1, mp2 )
endif
Gruß
Hubert
Antworten