lapso

Es geht. bei mir aber auch ohne""...komisch. Grüße Matze

Auf keinen Fall ist das empfehlenswert. Wollt ihr bei jedem Seitenaufruf Username+Passwort übergeben? Das ist, gelinde gesagt, dumm, aber vor allem überflüssig. Alles, was man braucht, ist eine SessionID. Das Passwort breucht ihr nur beim Login, danach nicht wieder. Ob Ihr nun auf vorhandene Libs zurückgreift oder euch eine eigene schreibt, ist irrelevant, aber Passwörter von Seite zu seite zu geben ist einfach fahrlässig. Nein, der Browser kommuniziert mit dem Webserver, dabei wird stets die Session-ID übergeben (in beide Richtungen). Es existiert also eine Sessino zwischen Server und Client. In diesem Forum hier findet das über ein Cookie statt. Der Webserver (respektive die dynamischen Seiten darin) kommuniziert mit der Datenbank meistens über ODBC. Hier ist der Webserver nun der "Client" und der DB-Server der "Server". Beide Verbindungen musst du unabhängig voneinander betrachten. Dann müßt Ihr euch wohl mal auf den Hosenboden setzen. Vorher sollte man gar nicht erst weiter programmieren, wenn solche grundlegenden Dinge nicht implementiert sind; später wird sonst allzuviel -verdammt viel- Arbeit anfallen. Ich kenne mich leider mit PHP nicht aus (komme aus der ASP-Ecke), kann dir aber trotzdem nur den Rat geben: Baut erst das Anwendungs-Framework (vor allem das Session-Handling), und macht euch erst danach an die Entwicklung der Funktionen der Anwendung. Und vor allem: Abgesehen vom Login-Request niemals das Passwort übergeben. Gruss Matze

Also, als erstes: RTFM. Will meinen, lies SelfHTML und schau dort, was du anders - sprich:falsch - gemacht hast. Dann wirst Du feststellen, dass Werte von Parametern per Standard in Anführungszeichen zu stehen haben. Dass einige Browser in einigen Fällen trotz fehlender Anführungszeichen das tun, was man von ihnen will, beweist noch nicht, dass der Code fehlerfrei ist. Also: width="100%" Lediglich bei rein numerischen Parameterwerten ist es verzeihbar, auf Anführungszeichen zu verzichten. Als Faustregel könnte man festlegen: Werte vom Typ String müssen zwingend in Anführungszeichen notiert werden. Sorry, aber manchmal bin ich eben etwas direkt... Grüße Matze p.s. den Parameter ALT bitte auch nicht vergessen, ist Vorschrift.

Das kann ich gut nachvollziehen *g*. Allerdings ist es so, dass wir eine Anwendung auf der eVB-Basis schreiben, da es gewisse Vorgaben gibt. Ich schlage mich auch nicht wirklich freiwillig mit VB-Dialekten herum Grüße Matze

aaaalso Blumen&Bienen. http ist insofern verbindungslos, als dass keine permanente Verbindung zwischen Client und Server zwischen zwei Requests besteht. Eine Verbindung existiert i.d.R. nur solange, wie eine Datei(HTML, GIF usw.) vom Client zum Server übertragen wird - dafür steht http. d.H.: Wenn ich eine Seite aufrufe(Request), erhalte(Response) und anzeige, danach einen Link darin zu einer weiteren Seite anclicke, hat dieser zweite Seitenaufruf nichts mehr mit dem ersten zu tun. Der Webserver kann erstmal nicht erkennen, dass ein Zusammenhang zwischen den beiden Requests besteht; erst recht kann er dich nicht als User identifizieren, denn alles was er hat ist deine IP-Adresse (die nicht zur Identifikation genügt). Das ganze hat auch erstmal nichts mit einer Datenbank zu tun; Der Client kommuniziert schließlich nicht mit ihr, sondern der Webserver tut das. Um nun - wie z.B. bei GMX - eine Sitzung(Session) zu verwenden, anhand welcher die eigentlich unabhängigen Requests einem Benutzer (einer Browserinstanz) zugeordnet werden können, muss die Browserinstanz sich eindeutig identifizieren lassen. Er benötigt also eine ID, die dem Webserver bekannt ist, und er muss diese ID bei jedem Request dem Webserver mitteilen, damit dieser den Request einer Session zuordnen kann. Hierzu sind zwei Methoden gebräuchlich: - Die Cookie-Methode: Der Webserver sendet ein sogenannten Session-Cookie, welcher eine ID enthält. Der Browser sendet bei jedem Request den Cookie im http-Header zurück, sodass der Server anhand der darin enthaltenen ID und seiner internen Session-Verwaltung erkennen kann, zu welcher Session der Request gehört. Der MS-IIS Server benutzt z.B. dieses Verfahren und stellt dem Programmierer damit eine sehr einfache, transparente Session-Verwaltung zur Verfügung. - Die GET-/POST-Methode: Die Session-ID wird dabei dynamisch in alle Links (z.B. href="zweiteseite.jsp?SID=3874521378") sowie alle Forms integriert, sodass bei einem Request durch diese Links/Forms die ID wieder zum Server übertragen wird. Diese Methode hat eben den Vorteil, dass sie auch ohne Cookies funzt. Im großen und ganzen macht der Webserver nicht mehr, als zu jeder Session einen Satz Variablen zu verwalten (z.B. UserID, Name); Anhand der Session-ID kann er stets den zur "requestenden" Browserinstanz gehörigen Satz von Daten identifizieren; somit ist es also möglich, personalisierte Dienste über http anzubieten. Zur Datenbank: Meistens wird innerhalb einer dynamischen Seite (JSP/ASP/PHP....) eine Datenbankverbindung aufgebaut, genutzt und dann wieder geschlossen. Das ist auch sinnvoll, da eine Datenbankverbindung nicht benötigt wird, wenn gerade kein Request bearbeitet wird. Also: Request->DatenbankÖffnen->Verarbeitung->DatenbankSchliessen->Response Ich hoffe, dass das erstmal hilfreich und soweit verständlich war, Grüße Matthias

heyjo. schonmal ein Anfang. Leider habe ich mit eVC++ noch nicht angefangen, oder soll ich besser sagen: gottseidank, da ich keine wirklichen C++-Kenntnisse geschweige denn Praxis besitze. Wir würden dafür auch eher einen Programmierer suchen, bevor ich damit anfange. Ich steige gerade in das eVB ein und habe dabei noch so meine Schwierigkeiten; und obwohl es sich an VBS anlehnt, fehlen wohl wichtige Dinge, und die Doku ist mE nicht so umwerfend praktisch (ich habe von MS schon bessere gesehen). Kennst Du dich mit eVB auch aus? Grüße Matze

wenn du z.B. Paint Shop Pro dein Eigen nennst, kannst du dort auch direkt die Farbcodes aus der Palette kopieren. gruss matze

Hallo Mädels, findet sich in der illustren Runde vielleicht jemand, der sich mit embeddedVB und HandheldPC auskennt? Ich fange gerade damit notgedrungenerweise an und wäre verdammt an einem Erfahrungsaustausch interessiert. Wenn noch jemand mit embedded VC++ dabei wäre, würde es nochmal interessanter werden.. Grüße Matze

Falsch für Version 4.x. --> RTFM Gruss Matze

http ist verbindungslos. (Das war schon immer so.) Gruesse, Matze

und Noch ein kommentar dazu: "_blank" öffnet *jedes mal* ein neues Fenster. Dies wird von allen Browsern soweit unterstützt. "_blank", "_parent" und "_top" unterscheiden sich dadurch ganz deutlich von allen anderen Werten. Ein beliebiger, anderer Wert wie z.B. target="xyz" öffnet zwar auch ein neues Fenster, aber es erhält dann den Namen "xyz". Jedes mal, wenn nochmal ein target="xyz" benutzt wird, wird damit also genau das erzeugte Fenster angesprochen. Mitunter ist das sehr unschön und wohl auch ungewollt. Ein immer wieder sehr hilfreicher Tipp: 1) erst SelfHTML lesen 2) dann Fragen stellen (RTFM sozusagen) Grüße Matze

Das würde ich nicht behaupten. Was ist mit VPN? Hat Schangsen... Gruss Matze

Aber: ein HTML-Menü lädt im Bruchteil der Zeit und erfüllt dabei genauso gut seinen Zweck: Navigation. Der primäre Zweck eines Menüs ist nicht Entertainment. Und wenn doch, dann sollte man Flash und nicht Applets benutzen. Meine Nachricht kam deshalb, weil es sich hier um ein dHTML-Problem handelt. Entsprechend deplaziert und OT ist dadurch der Hinweis auf einen Applet-Anbieter. Im Gegentum: Ich verstehe mich als Entwickler, nicht als Scriptkid. Ich denke, das kann man auch recht deutlich an meinen anderen Nachrichten erkennen. Im übrigen bin ich nicht gerade ein Freund des dHTML, auch das wirst du sicher schnell in diesem Forum in Erfahrung bringen können. Viele Grüße Matze

Cool, eine Seite die nur aus Appletts besteht.. (gesehen, genervt, geschlossen, vergessen) Grüße Matze

Stimmt schon. Würde ich mich auch nicht ran wagen, es sei denn, der Tag hätte 96 Stunden Versuch doch mal eine noframes-Version zu machen. (Ja ich bin ein er dieser Verfechter von framesetlosen Seiten). Grüße Matze

Naa-ja (rtfm) Das war erstens kein Tip sondern nur der Hinweis, dass in offiziellen Dokumentationen meistens äußerst Hilfreiches zu finden ist, zweitens ist es verdammt logisch, dass bei objFile.Copy nicht die Quelle anzugeben ist (wie würden wir fluchen, wenn wir es müßten. Stell Dir vor, du müßtest bei einem "Speichern Als.."-Dialog noch die Quelle angeben, obwohl sie bereits offen ist) und drittens ist das FileSystemObject keine Sprache, sondern eine Objekt. Aber das FileSystemObject hat durchaus sehr kritikwürdige Punkte, die man ruhig benennen darf; einer sieht so aus: Wenn man ein TextStream-Object mit fso.OpenTextFile erzeugt, wird das Format so angegeben: 0=ASCII -1=UNICODE -2=SystemDefault Wenn man aber ein TextStream-Object mit fso.CreateTextFile erzeugt, so sehen die Werte des Parameters wie folgt aus: false=ASCII(Default) true=UNICODE Da kann man schonmal vom Glauben abfallen. Nun glaub mal nicht, dass man diese Kenntnisse auf das FileCTL-Objekt von Windows CE anwenden könnte... aber das ist ein anderes Thema. Grüße Matze

Du stellst die Fragen in der falschen Reihenfolge. So wär´s besser: 1) Geht das? 2) Wie geht das? 3) Gibt es bereits eine fertige Lösung? 4) Wo gibt es diese? Und dann würdest Du bei Frage eins schon ein "Nein" erhalten, denn die Inhalte einer Website können natürlich nicht über die Ränder des Anzeigebereiches hinaus reichen. Die Idee, die DIVs in dem anderne Frame unterzubringen ist in diesem Fall nicht abwegig, ist aber etwas komplizierter zu codieren; möglicherweise ist dieses Konstrukt auch labiler, denn du bewegst dich damit immerhin im Bereich einer JavaScript-Kommunikation über zwei Webseiten hinweg. viele Grüße, Matze

Theorie ist folgendes (und damit berichtige ich meine vorige Aussage, dass das File-Object keine Copy-Methode besäße) Task Method Move a file File.Move FileSystemObject.MoveFile Copy a file File.Copy FileSystemObject.CopyFile Delete a file File.Delete FileSystemObject.DeleteFile So steht es in der FileSystemObject-Doku von mircosoft. Versuch es doch einfach mal. Grüße Matze

Guten Morgen Das ist wohl wahr. Wenn man alleine an einem Projekt rumwerkelt, verrent man sich schnell in Details, verliert sich am Design und erreicht früher oder später einen toten Punkt, der eine große Hürde darstellen kann. Bei 30 Tabellen für ein Forum würde ich mir allerdings Gedanken machen, ob das Projekt nicht etwas ausgeufert ist. Nach wie vor halte ich auch ein Session-Handling für recht einfach zu implementieren. Ich habe das irgendwann aus der Not heraus auch gemacht; Die Anforderung war, auf einem IIS5 eine WAP-Anwendung bereit zu stellen; da in ASP3 Sessions aber auf Cookies basieren (anders als in asp.net) und der tolle Nokia-Browser die nun so gar nicht verträgt, musste eine Lösung her. Es war zugegeben nur ein simples System (nur einfache Datentypen speicherbar), hat aber dafür bereits nach der zweiten Version absolut fehlerfrei gefunzt; Nutze das System auch weiterhin, da es zwar weniger performant, dafür aber weitaus skalierbarer ist als das von ASP3. Nunja. Lachsbrötchen-Alarm! Grüße Matze

Ich weiß ja nicht. Ein Forum ist doch im Vergleich zu einer Online-Warenwirtschaft eher ein Hasenfurz, oder? Ehrlich gesagt, Sessions sind eher das einfachste unter den Problemen. Und die paar Tables, die man in einem Forum benötigt, sollte man auch recht fix in den Griff bekommen. Wenn man erstmal, wie bei o.g. Warenwirtschaft 9 Tabellen verknüpfen muss, und das vorgegebene DB-Design nicht annähnernd vernünftig normalisiert ist (gewachsene Strukturen heißt das dann verniedlichend... *keuch*), dann wird das SQL erst richtig knifflig. Grüße Matze

muss es nicht heissen objFile.copyFile ? Jedenfalls wenn du das Scripting.FileSystemObject verwendest. CopyFile ist weiterhin keine Methode eines File-Objektes. Grüße Matze

- je größer die Datenmenge, umso besser ist die Frame-Variante - JavaScript wäre eine schicke Lösung in einem homogenen Browserumfeld (also Intranet) aber gerade dort ist die Verbindung i.d.R. schnell genug, um bei jeder Aktion einen Request zu machen, was wieder für die Frame-Variante spricht - die Frame-Variante belastet Datenbankserver und dessen Verbindung zum Webserver weniger - die Frame-Variante ist IMO wesentlich einfacher zu codieren und zu warten --> Feierabend! Gruss Matze

Es gehört also zu jedem Eintrag der ersten Liste eine weitere Liste mit unbestimmte Anzahl Einträge. Möglichkeit 1: Frameset. Im ersten Frame zeigst du die erste Tabelle an. Wird ein Eintrag ausgewählt, machst du einen Request in den zweiten Frame, in welchem dann die zweite Tabelle angezeigt wird. Unschön, aber funktional, schlank und kompatibel. Möglichkeit 2: JavaScript. Die erste Tabelle wird fest verdrahtet, aber mit einem Event rufst du eine Funktion auf, welche die 2. Tabelle anzeigt, sobald in der Ersten etwas gewählt wurde. Dabei müssen natürlich alle Daten sämtlicher, möglichen 2.Tabellen zu Client geschickt werden, entweder als JavaScript-Code oder als ein Haufen versteckter DIV-Layer. Vielleicht hilft das als erster Denkanstoß? Grüße Matze

Wenn ich mir meine Logs anschaue, so bilden Opera5/6, Mozilla und Netscape 6.x eine größere Fraktion als die ganze Netscape 4.x-Schiene. Nichtsdestotrotz muss eine Site im NC4.x immer funktionieren. Ob sie dabei ideal aussieht, ist eher egal. Oder sagen wir´s so: Wer mit einem Trabbi herumfährt darf sich nicht beschweren, dass Autobahn fahren keinen Spaß macht. Aber er muss trotzdem fahren können. Nicht? Gruss Matze

Steht doch in sienem Quellcode. Da soll sich was bewegen. Gerne hilfreich: Matze