Beiträge von sanyok

    Es scheint, dass man ab sofort ins Archiv der TBBETA-Mailingliste nicht mehr ohne eine vorherige Anmeldung kommt. Sonst sind die Einträge ausgegraut und es erscheint eine rote Fehlermeldung:

    AUTORISIERUNG VERWEIGERT (arc) Webarchive sind auf Listenabonnenten beschränkt. Falls Sie diese Liste unter einer anderen E-Mail-Adresse abonniert haben, sollten Sie entweder diese andere Adresse benutzen, oder Ihre Listenmitgliedschaft auf die neue Adresse aktualisieren.
    Sie müssen sich anmelden

    Werden die einem auch erfüllt?

    Ich habe z.B. mal gewünscht, dass man auch das Adressbuch so wie die Nachrichtendatenbanken komprimieren könnte, damit man Platz spart, weil alte Einträge immer noch darin bleiben. Diese Option hat man irgendwann implementiert. Oder als es früher noch den internen sowie den System-HTML-Betrachter (sprich IE) gab, wollte ich eine schnellere Umschaltung zwischen den beiden als nur über die Benutzereinstellungen haben. Wurde auch gemacht. Das von mir gewünschte OAuth 2.0 für Outlook.com hat man ebenfalls integriert.

    Es klappt also manchmal schon. Kommt wahrscheinlich vor allem darauf an, wie viele den sog. Wish bestätigen, wie einfach er zu verwirklichen ist und ob er nicht sowieso bereits auf der To-do-Liste von Ritlabs steht.

    Im BT kann man nicht nur Bugs, sondern auch Wünsche posten:

    Bernd
    9. April 2007 um 09:46

    Wie später?
    Habe schon eine Nummer

    Zu dem Zeitpunkt wusste ich nicht, dass du es bereits an Ritlabs über Support gemeldet hast. Wenn du eine Ticketnummer hast, dann poste sie auch im BT, damit sie einen Bezug haben. Die Nummer des damaligen Tickets hat apr ja auch dort erwähnt. In diesem Format kannst du sie auch schreiben. Kann jedenfalls nicht schaden.


    Nur dort steht nur ID, nichts von Ticket.

    Wenn du etwas an Support meldest, wird ein Ticket eröffnet und dieses erhält einer Nummer, sprich ID. Kurz heißt es dann auch TID. So steht's auch im BT.

    Das mit dem Thread %CURSOR ist gelöst und erledigt.

    Dann schreibe das auch so in dem BT-Eintrag, den Gwen in dem anderen Thema extra für dich erstellt hat.

    Habe gerade den BT Beitrag #0000713 bestätigt.

    Solltest du später eine Ticket-ID bekommen, poste sie ebenfalls im BT für alle Fälle.


    Wer ist hier der Administrator?

    https://www.batboard.net/wcf/team/


    Bei der Adresse im Impressum gibt mir niemand eine Antwort.

    Ja, Shen ist oft beschäftigt. Das kann dauern.

    Ich sehe gerade, dass die Mods die Benutzernamen nicht ändern können. Sonst hätte einer von uns weiterhelfen können.


    Welchen Thread meinst Du wegen Gwen?

    merlin-ch
    22. Februar 2024 um 16:03

    Die 3000 Nachrichten werden auch nicht gleichzeitig angezeigt, sprich in den Speicher geladen.

    Bekanntlich bleiben aber Daten im RAM, die dort schon mal waren. Komplett leeren kann man den RAM nur durch den PC-Neustart. Und wenn immer wieder etwas dazu kommt, dann ist er irgendwann voll. Hier wird aber wahrscheinlich nur ein Teil von RAM für diese Funktion von TB! reserviert und wenn dieser Teil überladen wird, dann stürzt TB! ab.


    Ich bin dort jetzt registriert :)

    Dann bestätige den o.g. BT-Eintrag sowie auch den, den Gwen für dich in einem anderen Thema erstellt hat. Mehr dazu unter "BugTracker-Verwendung".

    Das ist ja der Ordner "Imgfiles".

    Das ist der Ordner für Dateien, die aus dem Internet nachgeladen werden müssen, damit eine HTML-Nachricht richtig angezeigt werden kann. Die Fotos/Bilder von Absendern sind aber bereits im Adressbuch und müssen nicht nachgeladen werden. Mit Cache meinte ich daher so eine Art Pufferspeicher o.ä., was vielleicht nicht mal auf der Festplatte etwas speichert oder vielleicht irgendwo im Windows-TEMP-Ordner. Und wenn dieser Speicher nur eine begrenzte Kapazität hat, man aber viel mehr Bilder und dazu auch noch so schnell anzeigen lässt, dann ist er irgendwann voll und es gibt Fehlermeldungen oder gar Abstürze.

    Wenn RAM z.B. voll wird, dann wird der Rechner doch auch langsamer und kann sogar abstürzen. Also hat man hier eventuell die gleiche Situation.

    Im Moment sind es 69 Bilder mit einer Auflösung von 128x128, wo zusammen eine Grösse von 0,6 MB haben.

    Ja, aber wenn 3000 Nachrichten mit Bildern und Text angezeigt werden müssen, dann kann es durchaus sein, dass sie sich summieren, selbst wenn Wiederholungen dabei sind. 0,6 x 3000 sind schon mal fast 2 GB alleine für Bilder.

    Jedenfalls werden sich jetzt die Ritlabs-Mitarbeiter damit auseinandersetzen müssen. Man sollte nur regelmäßig den BT-Eintrag hochpushen, damit er nicht wieder in Vergessenheit gerät.

    Daher erneut der Rat, dich dort schnellstmöglich zu registrieren.

    Ich habe gestern Abend noch ein Ticket bei Ritlabs erstellt, mit einem Verweis auf diesen Thread hier.

    Verweise besser auf den o.g. BT-Eintrag, denn hier lesen sie kaum, wenn überhaupt, weil das ein inoffizielles Forum und dazu auch noch in einer Fremdsprache ist.


    Den Scrollbalken mit der Maus paarmal hin und her, geht es sehr schnell, bis der Absturz kommt.

    Also bei mir eben nicht sehr schnell. Ich musste bei den 3000 Nachrichten fast bis zu der letzten mit der Maus scrollen. Wollte sogar ursprünglich nach dem ersten erfolgreichen Test noch schreiben, dass der Fehler bei mir nicht auftritt, weil ich da wohl nicht bis zum Ende gescrollt habe.


    Vermute, dass der Fehler mit Zusammenhang mit dem Adressbuch steht.

    Ich kann mir das so vorstellen, dass TB! für Nachrichten einen speziellen Cache hat, der überfüllt wird, wenn man tausende davon mit Absenderfotos bzw. -bildern hat, was grundsätzlich selten vorkommt, denn wer fügt schon einer juristischen Person ein Foto bzw. Bild im Adressbuch hinzu? Wohl nur ein eM Client Umsteiger. ;)


    Wie schon geschrieben, kommt immer zuerst eine Fehlermeldung,

    Fehlermeldungen im Adressbuch habe ich hingegen nicht.

    Ich kann das mit der 64-bit Version auch nachvollziehen. Es erscheinen verschiedene Fehlermeldungen - mal nur AV wie oben, mal Invalid pointer operation, mal Invalid class typecast. Ich musste aber jedes Mal fast bis zum Ende scrollen. 2000 Nachrichten sind daher wohl in der Tat das Minimum. Sonst sieht man den Fehler nie.

    Das Programm scheint dabei auch nicht überlastet zu sein. Eine übermäßige Platzbelegung im RAM habe ich nicht feststellen können. Spielt also keine Rolle, ob das Programm 32- oder 64-bit ist. Irgendwie scheinen beide Versionen mit einer großen Menge von Fotos bzw. Bildern nicht zurechtzukommen.

    Wir hatten nämlich bereits ein ähnliches Problem mit einem sehr großen Foto als Anhang. Beim Öffnen in TB! gab's ebenfalls Fehlermeldungen. Allerdings hatte damals nur die 32-bit Programmversion damit Probleme, die 64-bit Version hingegen nicht. Diesmal scheint aber die Bit-Version irrelevant zu sein.

    Habe jedenfalls den o.g. BT-Eintrag #0000713 ergänzt. Mal sehen, ob Ritlabs darauf reagiert. apr aus BT ist übrigens Alexander Petrari, ein Ritlabs-Mitarbeiter, genauer gesagt vom Support. Er hat damals wohl von jemandem ein Ticket über Support mit der Nummer TID#65136 erhalten und es dann im BT eingetragen. Allerdings hat sich danach fast 10 Jahre lang niemand darum gekümmert. Da sieht man, was passieren kann, wenn es allen egal ist.

    Die Absenderadressen sind ja harmlos.
    Sind alles grosse Firmen, die ja jeder kennt bei uns.

    Sie sind nicht harmlos, sondern genauso gut für Spam wie eine private Adresse. Die Firmen zu kennen und ihre funktionierenden Adressen so einfach auf einem Teller zu präsentieren, sind zwei Paar Schuhe. Die meisten Firmen veröffentlichen ihre Adressen nicht, sondern haben nur Kontaktformulare, antworten dann zwar über eine Adresse, möchten aber vielleicht, dass diese geheim oder zumindest nicht für alle sichtbar bleibt. Solange also so eine Adresse nicht explizit auf der Firmenseite für Kontakte angegeben ist, muss man vorher um Erlaubnis der Firma fragen, so wie mit der Adresse einer Privatperson halt.


    Ich mache Euch eine Version, die abstürzt.

    Du hast geschrieben, dass es bei dir bereits mit 500 Nachrichten abstürzt. Dann mache bitte nur max. 500. Ich werde nicht noch einmal sinnlos über 9000 Nachrichten importieren, was bei mir ziemlich lange gedauert hat. Auch die Datei wird dadurch kleiner. Wer will schon 2,5 GB für einen kurzen Test zur Verfügung stellen.

    Und die Adressen exportiere bitte als LDIF. Also eine relativ kleine MBOX und eine LDIF. Dann könnte ich es noch einmal testen. Sonst musst du warten, bis es ein anderer tut.

    Und die alte ZIP solltest du löschen.

    Nein sicher nicht

    Nun, die Absenderadressen sind jedenfalls alle im Klartext zu sehen und damit ein gefundenes Fressen für die Spammer.

    Mit den 20 verschiedene E-Mails, meinte ich natürlich, 20 gleiche E-Mails, wo je eine andere Absender E-Mail-Adresse haben.
    [...]
    Der Rest ist ja alles multipliziert.

    Die ca. 9000 E-Mails aus der .mbox verursachen hier keinen Absturz. Die Bilder sind ebenfalls alle zu sehen.

    Bei einer Antwort oder Weiterleitung müsste der Mauszeiger sofort in den Textbereich springen, weil die wichtigsten Header-Zeilen bereits ausgefüllt sind. Daher ging's hier um neue Nachrichten.

    Ansonsten ja, die Makros wie %SUBJECT, %TO, %FROM usw. verändern natürlich die Header-Zeilen. Dafür sind sie ja auch da.

    Der Ordner, in welchem die Mails liegen, werden aber leider immer noch nicht angezeigt

    Ich dachte, dass es dir um die Sortierung geht. Du hast einen Ansichtsmodus erstellt und auf den neuen Tab angewandt. Die Nachrichtenliste wird jetzt so sortiert, wie in dem Ansichtsmodus eingestellt ist. Ziel erreicht.

    Ansonsten ist die Zusammenfassungsansicht in ihrer Darstellung unveränderbar.

    Vergiss bitte nicht, dass ich ein Schweizer bin.

    Das hat jetzt nichts mit Sprache oder Dialekt zu tun, sondern mit dem aufmerksamen Lesen.

    Deine Intention ist verständlich. Aufgrund der unter eM Client verwendeten Favicons willst jetzt auch in The Bat transparente Favicons verwenden. Ich habe lediglich darauf hingewiesen, dass die entsprechende Option im Adressbuch jedoch Foto heißt und daher zumindest ursprünglich nur für Fotos vorgesehen war, die wiederum grundsätzlich in JPEG und außerdem weder transparent noch quadratisch sind. Und eben für Fotos gab's und evtl. gibt's immer noch die obigen Vorgaben.

    Und wenn man jetzt anstelle eines Fotos etwas anderes in einem von den Vorgaben abweichenden Format einfügt, kann es zu Problemen kommen, die dann aber nicht am Programm liegen.

    Zumindest hat man mittlerweile als Hilfe ein zusätzliches Fenster eingebaut, in dem das zuvor gewählte Foto angepasst wird. Dort sieht man einen Rahmen, der eben der vorgeschriebenen bzw. empfohlenen Foto-Größe entspricht. Das ist für den Fall gedacht, wenn man ein viel zu großes Foto nimmt. Jedenfalls sieht man anhand dieses Rahmens, wie es später aussehen wird.

    Über die Tabs-Konfiguration kann man Ansichtsmodi zuweisen. Auf dem Screenshot sieht man nur den Standard-Tab Alle. Wenn man einen neuen erstellt, kann man in seinen Eigenschaften einen Ansichtsmodus wählen. Diesen wiederum erstellt man vorher in den Benutzereinstellungen unter Ansichtsmodus. So kann man auch verschiedene Tabs mit verschiedenen Ansichtsmodi erstellen und später bequem hin und her wechseln.