Laden...

Forenbeiträge von Cord Worthmann Ingesamt 1.215 Beiträge

22.09.2006 - 18:13 Uhr

Du musst für den Content ebenfalls eine Eigenschaft bereitstellen, die aber vom Typ Template ist.
Schau Dir dazu die Template-Klasse in der MSDN an - ist ein gutes Beispiel vorhanden.

Grüsse

22.09.2006 - 18:10 Uhr

Yap, ist ein IE-Bug.
Der IE rendert die <select> Tags immer zuletzt.
Das Problem lässt sich tatsächlich nur über das Ausblenden lösen - oder aber Du strukturierst die Seite so, dass es zu keiner Überlappung kommen kann.

Grüsse

22.09.2006 - 18:07 Uhr

Alles klar, ich verstehe.

Vergiss einfach diesen Atlas-Krempel und google mal nach "AJAX.NET pro"...
Das ist die bei weitem beste Implementierung für Remote-Callbacks in ASP.NET - das funktioniert sogar mit MSIE und deaktiviertem ActiveX bzw. älteren Browsern, die noch gar nicht XMLHttpRequest unterstützen, um im Hintergrund Requests vorzunehmen. Es werden XML und JSON unterstützt.

Allerdings handelt es sich um eine RAW-Implementation auf der Client-Seite - d. h., Du musst den Aktualisierungsvorgang selber in JS schreiben, kannst dabei aber eben auf die bedingungslose Bereitstellung von XMLHttpRequest (AJAX) setzen.
Wenn Du mittelmässig JS beherrscht, ist das kein Problem für Dich.

Grüsse

21.09.2006 - 23:32 Uhr

Du brauchst lediglich diese Struktur...


<div>
    <div style="float:left;width:120px">Titel:</div><div><input /></div>
    <div style="float:left;width:120px">Zusammenfassung:</div><div><input /></div>
    <div style="float:left;width:120px">Inhalt:</div><div><input /></div>
</div>

Dabei würde der äussere DIV-Container dann Dein eigentliches Control repräsentieren.
<input> ist das native HTML-Element zu "Textbox".
Du kannst natürlich auch "Textbox" verwenden - aber da Du ja sicher auch einen einheitlichen ViewState bzw. einheitliche Ereignisbehandlung haben möchtest, würde ich Dir raten, dass komplett selbst zu implementieren, da Du dabei auch sehr viel über die Control-Entwicklung/Funktionart lernst.

Dazu musst Du die Schnittstelle IPostBackDataHandler mit den Methoden LoadPostData und RaisePostDataChangedEvent implementieren, und die Methoden LoadViewState und SaveViewState überschreiben.
Dann überlegst Du Dir noch einen passenden Event-Namen, und schreibst Dir ein Control, dass selbst Ereignisse auslöst und seinen Zustand verwaltet.

In der MSDN findest Du zu allen Methoden hervorragende Beispiele.

Grüsse

21.09.2006 - 22:59 Uhr

Ohne Atlas zu kennen, vermute ich mal, dass es einfach den kompletten Inhalt des Knotens entfernt (und damit auch das script-Tag) und dann mit den neuen Informationen füllt.
Versuche, das Script einfach ausserhalb des zu aktualisierenden Knotens (Controls) zu platzieren.

Grüsse

21.09.2006 - 12:24 Uhr

Es kann sein, dass der MSIE die Variable dann immer übermittelt, wenn er auf "automatisch im lokalen Netz anmelden" aktiviert ist - einfach mal ausprobieren.
Ansonsten geht das nicht simultan.

Grüsse

21.09.2006 - 12:21 Uhr

@Lexodus:
Das meiste hat Lord Hessia ja bereits gesagt.
Ansonsten gilt:

  • immer ein äusseres DIV als Container verwenden
  • möglichst mit absoluten und 100% Weiten- und Höhenangaben arbeiten, um keine ungewollten Effekte zu erzielen
  • bei Block-Elementen immer display:block angeben, wenn normale Darstellung erwünscht ist, die in allen Browsern gleich aussieht.
  • In DIVs fester Breite nur Inhalte anordnen, die auch innerhalb dieser Breite sinnvoll umgebrochen werden können (oder overflow verwenden)

<html>
<head>
	<title>Layer Design</title>
	<style type="text/css">
	DIV#container {
		height:100%;
	}
	DIV#left {
		float:left;
		width:150px;
		height:100%;
		background-color:#CCCCCC;
	}
	DIV#right {
		float:right;
		width:150px;
		height:100%;
		background-color:#CCCCCC;
	}
	DIV#content {
		background-color:#EEEEEE;
		height:100%;
	}
	</style>
</head>
<body>
	<div id="container">
		<div id="left"></div>
		<div id="right"></div>
		<div id="content"></div>
	</div>
</body>
</html>

@ Lord Hessia:
Mit dem Layout ist das so eine Sache. HTML soll lediglich das Informationsgerüst der Seite darstellen. Und da die Seite von verschiedenen Geräten verschiedener Hersteller einwandfrei gleich interpretiert werden sollen, sind Regeln unerlässlich.
Wenn Du Dich erst einmal richtig in CSS eingearbeitet hast, und mit dem neuen IE auch die meisten lästigen Hacks entfallen (mit Glück sogar alle), dann wirst Du feststellen, wie genial diese Lösung eigentlich ist.

Deine Problematik verstehe ich allerdings nicht ganz. Wenn Du einem inneren DIV eine fixe Höhe verpasst und dem äusseren keine, dann wird dieses doch auf die entsprechende Höher erweitert. Min-width benötigt man da gar nicht.

Grüsse

21.09.2006 - 11:22 Uhr

Ohne Windows-Authentifizierung wird Dir aber keine Information übermittelt und lässt sich Gott-sei-dank auch nicht clientseitig mit JS/VBS ergattern.
Der Name steht in der bereits erwähnten HTTP-Header-Variablen LOGON_USER - die erhälst Du aber eben nur bei erfolgter WindowsAuthentifizierung.

Grüsse

21.09.2006 - 11:17 Uhr

Original von Cord Worthmann
Was aber tut man, wenn man es evtl. aus Anwendungs- oder Flexibilitätsgründen mit Datenhaltungsstrukturen zu tun bekommen kann, die sich so ohne weiteres auf eine DataTable bringen lassen [...]

Ich meinte natürlich nicht so ohne weiteres auf eine Table bringen lassen - aber das ist wohl auch so verstanden worden.

Original von Rainbird
Daten via DataAdapter in eine DataTable zu schreiben, um sie anschließend alle in einer Schleife zu durchlaufen, Objekte daraus zu erzeugen und diese Objekte in eine List<T> übergeben, ist sinnlos. Es macht die Architektur nicht flexiebler. In beiden Fällen tun die Datentransfer-Container nämlich genau das selbe: Abfrageergebnisse im Hauptspeicher vorhalten und ggf. deren Transport an den GUI-Prozeß via Serialisierung ermöglichen. Wenn man sich also für eigene Objekte als Datentransfer-Container entscheidet, sollte man lieber den DataReader verwenden um seine Objekte zu befüllen.

Da stimme ich zu - insofern hast Du hinsichtlich des dargestellten Anwendungsfalles Recht, eigene Container wären hier wohl doch ein unnötiges Mehr an Aufwand.

Grüsse

21.09.2006 - 01:18 Uhr

Was aber tut man, wenn man es evtl. aus Anwendungs- oder Flexibilitätsgründen mit Datenhaltungsstrukturen zu tun bekommen kann, die sich so ohne weiteres auf eine DataTable bringen lassen, oder wenn es sich um komplexe Objekte handelt, und/oder dann eventuelles Rückschreiben von Daten entsprechenden Aufwand bereitet.

Wahrscheinlich kann man generell keine allgemeingültige Empfehlung geben - es ist eben auch vom Anwendungsfall, Zeitaufwand, von zu erwartendenden möglichen Veränderungen und von der eigenen Phylosophie abhängig.
Wenn ich die Zeit dazu habe, würde ich heute immer eine Interface-gestützte Provider-Lösung anwenden. Meiner Meinung nach kann man die Daten so besser kapseln und ggf. vor nicht gewollten Veränderungen schützen bzw. hat die Möglichkeit bei entsprechendem Anwendungsfall ein AccessPermission-System o. ä. zu integrieren.

Wobei ich dazusagen muss, dass ich mich im Wesentlichen mit mitgliedergestützten Webanwendungen beschäftige, wenn ich Anwendungen schreibe. Und hier stehen Sicherheit, Flexibilität und Erweiterbarkeit an allererster Stelle, so dass der Business-Logik im Grunde nur gekapselte Objekte übergeben werden sollten, zumal gerade DataSets natürlich auch aus Performance-Gründen ungeeignet sind und man am besten nur mit DataReader und DbCommand arbeitet.

Grüsse

20.09.2006 - 17:00 Uhr

Dem würde ich mich anschliessen.

Es ist im Grunde doch auch nur ein bisschen Fleissaufwand, simple Wrapper für die ausgelesenen Daten zu schreiben, die Objekte müssen ja oft nicht mal grossartige Methoden besitzen und können die Eigenschaften readonly anbieten.
Dazu noch ein paar passende Schnittstellen festgelegt, und schon ist die volle Flexibilität gegeben.

Grüsse

19.09.2006 - 22:06 Uhr

this ist nicht unbedingt notwendig, wenn eine Eigenschaft/Methode der Instanz (hier Page) angesprochen wird, aber es ist konsequenter objektorientiert (und erleichtert einem das Schreiben, wenn man eine IDE mit Code-Completition verwendet 😉).
Über eckige Klammern spricht man die Index-Eigenschaft eines Objekts an, so fern es diese besitzt (wie bei Arrays).

Grüsse

19.09.2006 - 21:23 Uhr

Ich bin mir nicht sicher, was Du meinst...

string getParam = this.Request.QueryString["paramName"];
string postParam = this.Request.Form["paramName"];
string getOrPostParam = this.Request.Params["paramName"];

War's das?
😉

Grüsse

19.09.2006 - 18:25 Uhr

a:active
😉

Grüsse

19.09.2006 - 17:58 Uhr

Zu welchem Zeitpunkt wird denn das gewrappte ListControl erstellt?
Es werden nur die Ereignisse von hart-codierten Controls automatisch ausgeführt.
Bei dynamischen Controls muss der Seite spätestens in der Load-Phase mitgeteilt werden, dass entsprechende Controls beim Laden von ViewState und PostData berücksichtigt werden sollen, was die Voraussetzung für das Auslösen von Ereignissen ist.


void Page_Load(Object sender, EventArgs e)
{
    this.RegisterRequiresRaiseEvent(myCustomListControl.RealControl);
}

Grüsse

18.09.2006 - 21:20 Uhr

Das geht so natürlich nicht, da (wie richtig erkannt) bestehende Klassen nicht modifiziert werden können.
Es wird Dir also nichts anderes übrig bleiben, als die Klassen komplett selber zu schreiben, die über die gewünschten Eigenschaften verfügen sollen.
Da Du ja aber von den bestehenden Typen ableiten kannst, sollte der Aufwand überschaubar bleiben.
Wenn Du nun noch ein Interface definierst, das die abgeleiteten Klassen implementieren, kannst Du die entsprechenden Objekte auch durch Casten über diese Schnittstelle ansprechen.

Grüsse

18.09.2006 - 21:01 Uhr

Ihr Problem ist, dass Sie ohne runat="server" eben kein Control haben sondern lediglich literalen Code.
Nur Tags, die explizit als Control ausgewiesen sind oder von anderen Controls erstellt wurden, lassen sich auch als Control ansprechen.

Daher sollte das runat="server" Attribut in das Tag. Und wenn dieses dann auch noch XHTML-konform geschlossen wird, gibt es auch keine Parser-Exception...
<input runat="server" ... />

Grüsse

18.09.2006 - 20:50 Uhr

Original von DOOZER
Entschuldigt, wenn ich ein viel besprochenes Problem wieder aufwärme!

Wieso wächst der Speicher meines aspnet_wp.exe bei einem einfachen Postback ständig an?!?
Es gibt keine Logik hinter meinem Knöpfchen?!?
Was wird wo, warum gespeichert?

Daß .Net den Speicher nicht wieder freigibt ist ja schon echt das letzte!
Sollte es nicht in der Hand des Programmierers sein, Speicher wieder frei zu geben?!?

Ich kann dieses Verhalten hier nicht beobachten (Win2000 pro SP4, NETv2.0).

Ansonsten lässt sich zur Speicherfrage generell sagen, dass NET-Anwendungen viel Speicher unter Beschlag nehmen, wenn dieser zur Verfügung steht (wieso auch nicht).
Wird andernorts Speicherplatz benötigt, wird der ggf. von NET wieder freigegeben.

Wie soll man da Speicherlecks finden, wenn man keine Ahnung hat, wann sich der Worker-Prozess recycled?!?
Damit man keine Bugs im Framework findet?

Du brauchst Dich unter NET nicht mit Speicher-Management zu beschäftigen. Und es werden im Grunde auch keine Speicherlecks produziert.
Manchmal kann es sinnvoll sein, den GC manuell zum Löschen dereferenzierter Objekte zu veranlassen - aber unter ASP.NET wirst Du davon sicher kweinen Gebrauch machen müssen.

Wieso kann ich den Inhalt meiner Sessions nicht von Außen lesen?!?

Aus Sicherheitsgründen.

InProc oder Stateserver?

Das kommt ganz darauf an...
InProc bringt die beste Performance, belastet aber eben den Hauptspeicher des Servers.
StateServer oder SqlServer verringern die Performance, erlauben aber die Erhaltung der Session-Infos bei Server-Neustart und das Teilen des SessionState' mit anderen Servern (z. B. auf einer Webfarm).

Binär abgespeichert im SQL-Server?!?
Was soll das?!?

Wie kommst Du darauf?
Die Objekte werden natürlich serialisiert - daher ist es auch wichtig, dass alle in der Session abgelegten Objekte die Schnittstelle ISerializable implementieren, wenn die Möglichkeit besteht, dass evtl. nicht InProc verwendet wird.

Bitte überzeugt mich ASP.NET zu verwenden! LOL

Mfg FrankW

Fang' einfach an und informiere Dich ein bisschen mehr, anstelle schon nahezu polemisch loszudreschen - dann kommt der Spass von ganz alleine...
😉

14.09.2006 - 15:52 Uhr

Und Dein Objekt sollte die Schnittstelle ISerializable implementieren, da es bei anderen SessionModes als "InProc" zwischen zwei Anforderungen serialisiert/deserialisiert wird.

Grüsse

11.09.2006 - 14:40 Uhr

Wieso folgst Du nicht dem Link, den ich gepostet habe?
😉

Grüsse

09.09.2006 - 12:52 Uhr

Verwende ein zweites <form> Tag (ohne runat="server"), und setze dahinein generische <input type="file"/> HTML Tags. Nun wird kein Postback ausgelöst.

Der Nachteil - Du musst auf sämtlichen ASP.NET-Komfort verzichten oder eines der vielen HttpModule integrieren, die File-Upload wesentlich besser lösen als ASP.NET dies umsetzt...
http://asp.net/ControlGallery/default.aspx?tabindex=6&Category=41&q=upload

Grüsse

09.09.2006 - 12:43 Uhr

Wahrscheinlich sollen die Benutzerinfos an anderer Stelle erscheinen wie die Login-Inputs.
Allerdings wäre das mit ein bisschen Umgefrickel des LoginView unter Zuhilfenahme eines Literals oder Labels auch zu lösen.

Grüsse

06.09.2006 - 15:42 Uhr

So ein Algorithmus ist doch keine grosse Kunst.
Durchlaufe den vom Browser gesendeten string zeichenweise.
Setze einfach einen bool'schen Wert auf true, so bald Du ein < findest, und setze ihn auf false, so bald Du ein > findest.
Findest Du ein einleitendes Tag, und die Variable steht auf true, dann musst Du an der entsprechenden Stelle ein > einfügen - und andersherum...

Grüsse

p.s.: Du bist Dir über die enormen Risiken bewusst, die entstehen, wenn man vom Browser gesendetes HTML direkt in die Seite übernimmt, oder? (Stichwort: HTML-Injektion, Cross-Site-Scripting etc...)

06.09.2006 - 15:30 Uhr

Schau Dir einmal die System.Management.ManagementEventWatcher Klasse an.
Damit sollte das vergleichsweise komfortabel machbar sein.

Unter den Beispielen dazu findest Du auch Hilfe bezüglich der Abfragemöglichkeiten bzw. wie man welche Events buchen kann.

Grüsse

05.09.2006 - 22:57 Uhr

Du wirst Objekt, die an eine Browser-Instanz (Anwendung) gebunden sind, wohl kaum in die Zwischenablage kopieren können.
Wenn zwischen setzen und auslesen der Daten z. B. ein Refresh läge, könntest Du gar nicht mehr an das Objekt kommen, da es zerstört ist, und die Referenz in der Zwischenablage auf eine invalide Speicheradresse verweist.

Versuche stattdessen das Objekt zu serialisieren (z. B. myDiv.parentNode.innerHTML), dann abzulegen und später wieder zu deserialisieren (z. B. myParent.insertAdjacentHTML).

Grüsse

03.09.2006 - 16:20 Uhr

Du musst auf jeden Fall PHP 5.0 verwenden und solltest davon absehen, prozedural zu arbeiten.

Mit Mono und mod_mono kannst Du ASP.NET 1.1 auch auf Linux/Apache betreiben - ASP.NET 2.0 wird wohl auch in Bälde komplett implementiert sein.

Ich würde Dir allerdings dazu raten, komplett zu ASP.NET zu wechseln und C# anstelle PHP zu verwenden.

Grüsse

21.08.2006 - 15:53 Uhr

Yup, DataSets haben in Web-Anwendungen nichts zu suchen. Keine Ahnung, warum sie in so vielen MSDN-Examples verwendet werden. Bei Desktop-Apps, wo man Werte aktualisiert und rückschreibt, ist das okay, aber für die Einmalige Verwendung des Auslesens sind sie definitiv zu inperformant.
DB-Zugriffe machen locker 90% oder mehr der Zykluszeit im Web aus, da muss man optimieren, wo's geht. Daher sollte man nur mit DbCommand und DataReader arbeiten.

Paging kannst Du auch über SQL-Statements realisieren.

Grüsse

20.08.2006 - 23:18 Uhr

Original von Waschbecken
Ich sehe hier immer mehr Leute, die sich angelockt durch das Klickibunti von VS 2005 daran machen, ihr durch die Desktopprogrammierung geprägtes Denken auch aufs Web zu drücken, und mehr ist ASP.NET halt nicht - nen serverseitiges Framework um HTML & Co. zu generieren. Vieles was du mit Winforms einfach zusammenklickst, musst du halt für den Browser mühseelig selbst bauen.

Du sprichst mir aus der Seele!

@demondriver235:
Du darfst einen "Wechsel" zu ASP.NET nicht als Migration verstehen, die zu 100% sämtliche Funktionalität ds Desktops ermöglicht.
ASP.NET ist eine Anwendung fürs Web - d. h., Du kannst per ASP.NET Prozesse abwickeln, die eine zentralisierte Datenhaltungsstruktur voraussetzen, aber nichts regeln, was den Client allein betrifft.
Darüberhinaus ist ASP.NET, wie Waschbecken bereits trefflich ausgedrückt hat, lediglich ein "HTML-Wrapper", der mitnichten die Funktionalität von Windows.Forms bereitstellt (auch wenn z. B. die gesamte Web2.0 Diskussion das bisweilen vermitteln möchte).
ASP.NET kann lediglich auf die rudimentären Funktionalitäten von HTML, aufgepeppt mit JS und CSS, zurückgreifen - und die erlauben oft keine direkte Umsetzung oder sind schlicht inperformant.

Teile doch mal mit, was Du überhaupt ins Web auslagern möchtest.

Grüsse

19.08.2006 - 15:45 Uhr

Ich würde sagen, das hängt ziemlich von der Art des Projekts ab.
Sehr spezielle Anwendungen und/oder welche, bei denen keine Änderung der Datenhaltung vorgesehen ist, können sicher auch unter Verwendung des DataBinding entwickelt werden.
Ansonsten halte ich das Provider-Prinzip für die Top-Design-Lösung, wobei das natürlich einen erheblichen Mehraufwand an Arbeit bedeutet. Man muss da schon genau abwägen.

Grüsse
Cord

17.08.2006 - 15:03 Uhr

Das ist eine Sicherheitsvorkehrung, die Sinn macht.
Die SessionID steht ab ASP.NET 2.0 auch im HTTP-Header. Wenn Du also nur den URL kopierst, fehlt die Information im Header, und Du wirst folgerichtig nicht authentifiziert.

Stelle Dir mal vor, ein Forum wird mit ASP.NET/Auth:cookieless (ohne diesen Schutz) betrieben, und Du postest einen Link zu einem anderen Beitrag. Dann würde ja jeder, der den Link klickt, auf einmal Deine Sessiondaten erhalten und würde im ungünstigsten Fall soagr als Du authentifiziert...
😉

Grüsse

16.08.2006 - 16:29 Uhr

Original von verbalhoodz
Das kann ich ja nicht da der Password wechsel nicht als Benutzer sondern als technischer Benutzer erfolgen soll.

Dann muss sich der Anwender eben als technischer Benutzer authentifizieren, ist doch kein Problem...
😉

Grüsse

15.08.2006 - 22:51 Uhr

Die Windows-Authentication verwenden, um den User zu veranlassen, sich mit dem benötigten Account anzumelden, und...

<identity impersonate="true" />

...der web.config hinzufügen.

Grüsse

15.08.2006 - 22:47 Uhr

Dafür wirst Du Dir höchstwahrscheinlich ein eigenes Control schreiben müssen, falls Du nichts passendes im Web finden solltest.
Falls Du es inkauf nimmst, die Funktionalität ein wenig einzuschränken, kannst Du Dir sicher auch eine Darstellung per DataGrid zusammenschrauben.

Grüsse

14.08.2006 - 17:01 Uhr

Einfach den kursiven Teil weglassen...
😉

"Server=localhost;Port=3306;Database=jetzt;uid=root;pwd=;"

Grüsse

13.08.2006 - 15:43 Uhr

Es gibt etliche Designer-Attribute, die Du Deinem Control hinzufügen kannst. Versuche es mal damit.

Grüsse

13.08.2006 - 15:41 Uhr

string sql = "SELECT * FROM [table] WHERE ID=" + this.Request.QueryString["ID"];

Das lädt allerdings hervorragend zu SQL-Injection ein, vor allem bei URL-Parametern (weil man die so komfortabel in die Adresszeile des Browsers eintippen kann 😉).
Schaue Dir mal parametrisierte Abfragen an - das ist vom Prinzip quasi eine StoredProc.

Übrigens solltest Du vor allem bei Webanwendungen aus Performance-Gründen auf SELECT * Statements verzichten, da bei jedem Aufruf erst einmal datenbankintern ein SELECT über die Cols einer Tabelle läuft, um festzustellen, wie viele Spalten vorhanden sind. Auch wenns mehr Schreibarbeit bedeutet, ist es immer besser, nur die Spalten abzufragen, die man auch tatsächlich benötigt (und wenn man im Zweifelsfall sogar alle tippt).

Grüsse

13.08.2006 - 15:32 Uhr

Ich verstehe nur Bahnhof...
😉

Grüsse

11.08.2006 - 01:23 Uhr

Nun ja, diese Werte vergleichst Du mit dem beizeiten gespeicherten Wert der letzten Abfrage um festzustellen, ob eine Nachricht neu oder bereits bekannt ist?!
Nur 'mal so als Anregung...

// EDIT:
...'ist eigentlich nicht mehr, als von der einen Ecke zur anderen zu denken

Grüsse

10.08.2006 - 20:49 Uhr

Eine andere Möglichkeit wäre noch, die Mails dennoch herunterzuladen ohne sie zu löschen.
Dann parst Du den Header der einzelnen Mails, und suchst Dir den ersten Received Wert heraus - der wird vom Mailserver angehängt und enthält das Datum und die Uhrzeit des Eintreffens der Mail.

Grüsse

10.08.2006 - 20:43 Uhr

Natürlich geht das...

Nur ist die Art und Weise, wie Du Layout-Fragen bei HTML-"Objekten" behandelst, eine völlig andere als bei Windows.Forms, denn HTML hat nur wenige eigene Eigenschaften - das Layout wird durch die Style-Sprache CSS ergänzt.

Dabei können aber Angaben zu verschiedenen Elementen miteinander kollidieren, da sie im Einzelnen bei der Darstellung angewendet werden. Du kannst also niemals eine generelle Grösse angeben und erwarten, dass diese ohne Berücksichtigung der Inhalte auch konsequent beibehalten wird - sprich bei Viewport-Size xy wirst Du zwangsläufig einen Scroller erhalten o. ä. (es sei denn, Du clippst die Inhalte, wodurch sie dann bei zunehmender Verkleinerung des Fensters teilweise abgeschnitten werden).

Die von Dir zitierte PHP-App hat das für ihren speziellen Anwendungsfall geregelt.
Du hast aber eine ganz andere Situation und musst das daher selber umsetzen - es gibt keine generalisierte Resize-Lösung für HTML.

Grüsse

09.08.2006 - 21:51 Uhr

WebForms (eine bescheuerte und irreführende Namensgebung) haben absolut gar nichts mit Windows.Forms gemein ausser dem Namen.
Ich würde Dir dringend raten, Dich ein wenig in die Grundlagen von HTML und CSS einzuarbeiten, bevor Du mit ASP.NET anfängst.
Wenn Du einige HTML/CSS Kenntnisse hast, schaust Du Dir mal den von ASP.NET generierten Quelltext an - dann erkennst Du den eigentlichen Hintergrund von ASP.NET.

Grüsse

09.08.2006 - 21:47 Uhr

Lade doch immer die vorhandenen Mails herunter und lösche sie auf dem Server. So weisst Du auch, ob Du neue Nachrichten bekommen hast.

Grüsse

09.08.2006 - 21:38 Uhr

Mit UserControls...

Grüsse

07.08.2006 - 22:50 Uhr

Interessant (und auch ausfüllend) wäre als Thema evtl. eine Diskussion verschiedener Algorithmen zur Berechnung komplexer Hüllen. Dies ist ein wesentlicher Prozess bei der Abbildung/Berechnung grafischer Objekte in den 2D-Darstellungsbereich.
Im Einzelnen geht es dabei um die Erfassung der minimalen Anzahl äusserer Punkte, die es braucht, um einen komplexen Körper zweidimensional darzustellen - also die Bestimmung der Umhüllenden.

Stichworte dazu sind "Graham Scan", "Quickhull", "Jarvis March"....

// EDIT:
Dabei könntest Du ja einen der Algorithmen implementieren.
Programmiertechnisch gesehen wäre das unteres Mittelniveau

Grüsse

07.08.2006 - 22:33 Uhr

Du musst schon eine Referenz zum entsprechenden Webpart Quellcode posten, damit sich jemand dazu äussern kann...
😉

Grüsse

07.08.2006 - 22:28 Uhr

Du hast etliche Scripts rausgehauen - zu jedem Eintrag der Liste existiert in der vorhergehenden Version ein Javascript, in welchem die Function getId aufgerufen wird.
Mir fehlt die Zeit, die Scripts der Seite nachzuvollziehen, aber Du solltest Dir das einmal anschauen.

Grüsse

01.08.2006 - 21:48 Uhr

@DaVinci:
Nein, nicht ohne Verzeichnisdienst...
😉

Grüsse

p.s.:
Übrigens hatte ich mich gar nicht auf Deinen Code bezogen sondern auf meinen, denn Dein zwischenzeitliches Posting hatte ich noch nicht zur Kenntnis genommen.

01.08.2006 - 19:52 Uhr

Yo - habs jetzt auch mal ausprobiert, die beiden slashes nach "WinNT:" müssen weg oder der NetName bzw. die IP des PDC muss angehängt werden.
Aber dabei fällt mir ein, Du wolltest ja nicht die vorhandenen Domains bzw. Workgroups listen sondern die Rechner Deiner Workgroup...
😉

Wenn Du keinen PDC oder AD/LDAP-Server laufen hast (was ich jetzt mal vermute) und damit auch keinen Verzeichnisdienst abfragen kannst, bleibt Dir nichts anderes übrig, als NetServerEnum zu wrappen.
Schau mal z. B. bei google-groups unter "NetServerEnum und .NET", da gibts einige Code-Beispiele (auf codeproject AFAIK ebenso).

Grüsse

01.08.2006 - 18:47 Uhr

Dort nichts anderes eintragen - "Domain" ist Filtername.
😉

Grüsse