Die Gross- und Kleinschreibung in Javascript kann manchmal ziemlich reinlegen, ich habs auch nicht bemerkt 🙂
Im Prinzip ist die Groß-/Kleinschreibung bei JavaScript einheitlich. Nach jedem Wort kommt ein Großbuchstabe, und zu Beginn ein Kleinbuchstabe. "Timeout" ist ein Wort, deshalb auch kein großes O.
Ich muss sagen ich freue mich sehr auf die Final der Visual Studio 2008. Die volle IntelliSense-Unterstützung für JavaScript wird es leichter machen, solche Fehler zu vermeiden. Das hat in der Beta2 schonmal sehr gut ausgesehen! 🙂
Solche Fehler sind vermeidbar indem man sich entsprechende Dokumentationen reinpfeift. Es gibt kein "setTimeOut". Es gibt dafür aber "setTimeout". Wenn du die Fehlerkonsole von FireFox bemühst, kriegst du die Fehler auch angezeigt.
Die Server von ECS-Webhosting sind auch zu empfehlen. Meiner läuft ohne Probleme und der Support ist äußerst fix.
Ich bin weder klein noch ein JavaScript-Gott, aber schön dass es geklappt hat.
Im body-Tag von der Masterpage oder per JavaScript mit:
document.onload=function() {
alert('Foo');
}
Jürgen Gutsch hat dir die Lösung schon genannt. Natürlich kannst du Controls zur Laufzeit hinzufügen. Hat es bei dir nicht geklappt?
Ohne HTML geht natürlich garnichts. Auch alle ASP.NET Servercontrols werden letztendlich bei der Anzeige in HTML / CSS und teils auch JavaScript umgewandelt. Ohne HTML geht im Web nicht viel, es sei denn du nutzt proprietäre Plugintechniken wie Flash oder Silverlight.
Hallo sanchezBrem,
wow, knifflig. Aber eben habe ich es hinbekommen. Also zuerst setzt du die UseSubmitBehaviour-Eigenschaft deiner Buttons auf false.
Dann musst du das JavaScript-Event onkeypress nehmen, nicht onkeydown. Dann funktioniert es mit folgendem Code:
if ( (event.which && event.which == 13) || (event.keyCode && event.keyCode == 13)) {
document.all.Button1.click();
return false;
}
else {
return true
};
Ein anderer Ansatz wäre gewesen, dem Textfeld vor dem Abschicken per JavaScript den Focus zu entziehen. Dann kommt der Inhalt aus der Autovervollständigung nämlich auch ins Feld.
Und nun noch ein Riffel: Du solltest dein JavaScript ein wenig standardkonformer schreiben. Der Firefox verzeiht document.all nicht, das ist nämlich Microsoft-proprietär. Nimm' lieber document.getElementById(), da kriegst du ebenfalls das Handle. Ach, und kommt keyCode nicht normalerweise aus dem an den Handler übergebene event-Objekt statt aus dem statischen window.event?
Naja, im IE läuft's.
Ich habe gerade keine Statistik zur Hand, aber der Anteil der Benutzer die JavaScript aktiviert haben, ist sicherlich höher, gerade in unserer heutigen Zeit, in der ohne Waschmittel und Web 2.0 fast nichts mehr geht.
Ich halte es diesbezüglich immer so: Entwerfe ich eine Homepage, verzichte ich auf JavaScript. Entwerfe ich hingegen eine Webanwendung, setze ich JavaScript intensiv ein, denn dann kann ich JavaScript-Support als Systemvoraussetzung münzen.
Wie auch immer, in ASP.NET kann man JavaScript-freie Seiten schreiben. Dazu muss man sich aber vor Augen halten, dass es mit reinem HTML nur eine Möglichkeit gibt, ein Formular an den Server zu schicken: Den Submit-Button. Wenn du also darauf verzichtest, dass Postbacks durch veränderte Listen / veränderte Textboxen, geklickte Links o.Ä. erzeugt werden, und dich nur auf den Submit-Button beschränkst, wird deine Webanwendung kein JavaScript enthalten.
Genaugenommen wird JavaScript nur in deine Seite kopiert, wenn das "AutoPostBack"-Property für ein Seitensteuerelement gesetzt ist.
Viel Geschwafel, kurzer Sinn: Sorge dafür dass jedes Steuerelement auf deinen Seiten AutoPostBack mit false belegt, und schon bist du von JavaScript befreit.
Der Browser verrät dem Server, ob Cookies unterstützt werden. Diese Information müsste im Request übertragen werden. ASP.NET reagiert bei AutoDetect eben passend darauf.
Wozu brauchst du eine statische, "userspezifische" Datenbankklasse? Verbindungen dürfen eh nicht offengehalten werden und userspezifisch sollte eine Datenbankklasse ja auch nicht sein.
Google mal nach dem Lebenszyklus einer ASP.NET Seite. Wenn mich nicht alles täuscht war dieser wie folgt:
Initialisierung / Seitenaufbau
Auswertung von Formulareingaben
Auswertung des ViewState
Behandlung von Control-Events wie Button.Click
Validierung
Data Binding
Ich wohne in der Nähe von Wörth und fände das Ganze ebenfalls interessant.
Hallo Bernd,
ich habe die Frage nicht gestellt.
Also ❔ nennt sich ternärer Operator.
Bei einem typisierten DataSet kannst werden deine Zellen durch Properties dargestellt, welche natürlich typsicher sind, und somit Fehler beim Programmieren vermeiden. Untypisierte, herkömmliche DataSets bieten dies nicht, hier kannst du auf die Zellen lediglich durch Collections zugreifen, welche dir object-Typen zurückliefern.
Wie du dir vorstellen kannst, ist für ein typisiertes DataSet einen ganzen Batzen Codegenerierung nötig, wobei wir auch schon bei den Nachteilen wären. Typisierte DataSets sind langsamer und die Codegenerierung ist hierbei nicht sonderlich sauber. Dafür bieten sie einen höheren Komfort beim Programmieren durch IntelliSense und typsicherheit.
Es gab hier in der Vergangenheit auch Threads zum Thema. Bemühe bitte die Forensuche.
Ich kannte den Operator auch nicht, finde ihn aber ziemlich geil, gerade bei der Auslesung assoziativer Listen ist er ziemlich nützlich. Danke herbivore
Sorry ich verstehe immernoch nicht, warum "meinprojekt" in deiner URL überhaupt vorkommt. Da es der Wurzelordner des Projektes ist dürfte der überhaupt nicht festgeschrieben werden. Und wie norman_timo bereits geschrieben hat, erreicht man mit dem ~-Operator das Wurzelverzeichnis. Damit sollte dir es wohl möglich sein, eine projektverzeichnisnamenunabhängige URL zu schreiben.
Es geht darum dass du die Datenbank füllst, unabhängig davon ob die Verbindung klappt oder nicht, und die Exception auch nicht abfängst.
Hallo Golo,
kannst du vielleicht deinen Code posten?
Also dass du es mit einem HTTP Handler machst, kann nicht das Problem sein. Ich habe nämlich auch schon einen geschrieben der Grafiken behandelt und da war das ultraflott.
Liegt es vielleicht am Server selbst?
Ich bin der Meinung, dass du dann die Spalten über die Columns Auflistung manuell hinzufügen musst. Genau das ist ja die Funktion von AutoGenerateColumns. Spalten werden beim DataBinding automatisch generiert. Setzt du das auf "false", musst du's manuell tun.
Zu deinem Columns.Count Problem: Das Eventhandling (Button.Click etc.) wird auf ASP.NET Seiten vor den DataBinding-Routinen ausgeführt. Das heißt zum Zeitpunkt der Eventverarbeitung ist Columns.Count natürlich 0, weil die DataBinding Automatisierung erst danach erfolgt, und AutoGenerateColumns auch erst dann in Kraft treten kann.
Edit: Wenn du deine Columns.Count Abfrage in Page_PreRenderComplete packst, wird Columns.Count vermutlich nicht 0 sein.
@Peter Bucher: Warum darf Data Binding nur beim ersten PostBack erfolgen? Klar, standardmäßig wird der Zustand durch den ViewState ja persistent gemacht, aber das kann ich ja kontrollieren. Korrigiere mich, wenn ich mich irre.
Vielleicht verstehe ich dich ja falsch, aber ist das nicht ein rein administratives Problem?
Die Weiterleitung muss so eingerichtet werden, dass sie in das Wurzelverzeichnis (das Verzeichnis über "meinprojekt") zeigt, und es somit keinen Unterschied für deine ASP.NET Anwendung macht, ob der Benutzer von Domain A oder Domain B kommt.
Es würde ja wunderbar funktionieren wenn da
src="ScriptResource.axd?..."
stehen würde
Guter Punkt, warum steht das denn da nicht? "meinprojekt" ist ja dein Projektverzeichnis. Warum musst du in dieses Verzeichnis überhaupt verweisen? Was liegt denn darüber im Wurzelverzeichnis?
Wenn du mehrere Spalten in der Masteransicht hast, ist das GridView eine gute Wahl. Aber eine DropDown-Liste oder Ähnliches tut es bei einfachen Einträgen auch. Ich denke das bleibt deinem Geschmack überlassen.
Mhmm ich fahre immer recht gut mit einer MemoryStream-Instanz, welche ich beschreibe und anschließend in die Response haue (Response.BinaryWrite). Beim PNG Format gibt es sowieso Probleme, direkt in die Response zu schreiben. Zumindest bekam ich dort immer eine allgemeine GDI+ Exception.
Du kannst den Primärschlüssel natürlich mittels SQL festlegen, hier unterscheidet sich allerdings die Syntax bei verschiedenen SQL Dialekten. Wie das bei Access aussieht, habe ich leider nicht im Kopf.
Bei DataAdapter.Fill werden Exceptions geworfen, wenn es ein Problem mit der Datenbank oder den Statements gibt. Deshalb gehört es auch in Try. Finally stellt den Codeblock dar, der immer nach einem Try-Block ausgeführt wird. Ganz egal ob eine Exception geworfen wurde oder nicht. Und du sagst mit deinem Code folgendes aus:
Schau' ob du die Datenbank öffnen kannst. Und egal ob es klappt oder nicht, lies' die Daten aus der Datenbank.
Macht das in deinen Augen Sinn?
Im Übrigen musst du die Connection nicht manuell öffnen, das macht DataAdapter.Fill für dich von alleine. Und dass du anhand einer fehlgeschlagenen Verbindungsöffnung schaust ob die Datenbank noch erstellt werden muss ist auch nicht gerade sauber.
Der Primärschlüssel ist eine Spalte. Das stellst du in deinem Access ein.
Dein Datenzugriffscode ist im Übrigen nicht gerade sauber. DataAdapter.Fill im Finally-Block? Das gehört in Try.
Streng genommen haben Klassen wie BindingSource oder MessageBox dort auch nichts verloren.
Hallo da_owa,
bitte poste doch den entsprechenden Datenzugriffscode, wir sind schließlich keine Hellseher.
Scheinbar lässt du aber Insert/Update/Delete-Statements für den Zugriff generieren, wobei jedoch eine Primärschlüsselspalte benötigt wird, was von deinem Select-Command nicht geliefert wird.
Hallo herbivore,
ich stimme dir voll und ganz zu - Konkurrenz ist wichtig. Als Webentwickler wünscht man sich entgegen diesem vernünftigen Gedanken jedoch schon gelegentlich einen einzigen Standard, an dem man sich orientieren kann.
Unabhängig davon bezweifle ich, dass wir auf dem Browsermarkt eine weitere Lösung benötigen. Web 2.0-Browser hört sich für mich nach einer Lösung auf der Suche nach einem Problem an. Schnell hin oder her.
Yeah, noch ein Browser in dem man seine JavaScripts und CSS Ressourcen testen darf. Als wären Opera, FireFox, IE, Konquerror und wie sie alle heißen noch nicht genug. Ging es nach mir, würde es nur einen Browser geben. Ein Browser sie zu knechten, sie alle zu finden, ins Dunkel zu treiben und ewig zu binden*. 😉
* Nein ich bin nicht verrückt. Das ist ein Herr der Ringe Zitat.
Hallo,
ich habe versucht ein Excel Test-AddIn zu schreiben, doch wenn ich das AddIn unter COM-AddIns in Excel hinzufügen will, erhalte ich die Fehlermeldung, dass die Assembly kein gültiges AddIn sei, ohne eine genauere Fehlerbeschreibung. Das Projekt wurde von Hand in VB Express erstellt, als reguläre Klassenbibliotheksvorlage.
Das AddIn an sich hat keinen Sinn - es ist lediglich ein Test. Angezeigt werden soll ein Button auf den geklickt werden kann und eine MsgBox anzeigt.
Hier mein Code:
Imports System.Windows.Forms
Imports System.Runtime.InteropServices
Imports Microsoft.Office.Core
Imports Microsoft.Office.Interop
<ComVisible(True)> _
<Microsoft.VisualBasic.ComClass()> _
Public Class InfoBox
Implements Extensibility.IDTExtensibility2
Private excelApplication As Excel.Application
Private WithEvents commandBarButton As CommandBarButton
Public Sub Show()
MessageBox.Show("Hallo, dies ist eine Information", "InfoBox v0.1", MessageBoxButtons.OK, MessageBoxIcon.Information)
End Sub
Public Sub OnAddInsUpdate(ByRef custom As System.Array) Implements Extensibility.IDTExtensibility2.OnAddInsUpdate
End Sub
Public Sub OnBeginShutdown(ByRef custom As System.Array) Implements Extensibility.IDTExtensibility2.OnBeginShutdown
Me.Dispose()
End Sub
Public Sub OnConnection(ByVal Application As Object, ByVal ConnectMode As Extensibility.ext_ConnectMode, ByVal AddInInst As Object, ByRef custom As System.Array) Implements Extensibility.IDTExtensibility2.OnConnection
If (TypeOf Application Is Excel.Application) Then
excelApplication = CType(Application, Excel.Application)
End If
End Sub
Public Sub OnDisconnection(ByVal RemoveMode As Extensibility.ext_DisconnectMode, ByRef custom As System.Array) Implements Extensibility.IDTExtensibility2.OnDisconnection
End Sub
Public Sub OnStartupComplete(ByRef custom As System.Array) Implements Extensibility.IDTExtensibility2.OnStartupComplete
Me.AddCommandBars()
End Sub
Public Sub AddCommandBars()
Dim officeBar As CommandBar = excelApplication.CommandBars.Add("MsgAddInBar", MsoBarPosition.msoBarTop, MsoBarType.msoBarTypeNormal, True)
commandBarButton = CType(officeBar.Controls.Add(MsoControlType.msoControlButton, 1, , , True), CommandBarButton)
With commandBarButton
.DescriptionText = "Starts the MsgAddIn v0.1"
.Style = MsoButtonStyle.msoButtonCaption
.Caption = "MsgAddIn v0.1"
End With
officeBar.Visible = True
officeBar = Nothing
End Sub
Public Sub commandBarButton_Click(ByVal ctrl As CommandBarButton, ByRef cancelDefault As Boolean) Handles commandBarButton.Click
Show()
End Sub
Public Sub Dispose()
GC.Collect()
If (excelApplication IsNot Nothing) Then
Try
Runtime.InteropServices.Marshal.ReleaseComObject(excelApplication)
Finally
excelApplication = Nothing
End Try
End If
End Sub
End Class
Bin für jede Hilfe dankbar.
LukeGee, das war nicht böse gemeint - eher eine scherzhafte Bemerkung. Ist ja ok, wenn du Abwechslung auf dem Desktop brauchst. 🙂
Also wenn ich einen dynamischen Button in PageLoad hinzufüge (was du ja letztendlich auch machst, erzeugeListe wird ja dort aufgerufen), und einen Click-EventHandler anbringe, wird der jedesmal ausgeführt. Am dynamischen Button selbst liegt es wohl nicht, das hätte mich gewundert. Hast du vllt. ein ausführbares Miniprojekt?
Also ich kann die Probleme auch lediglich im WPF Bereich bestätigen.
Wenn du schon eine lange Suche hinter dir hast, hat dir der Link vermutlich nicht geholfen oder?
http://aktuell.de.selfhtml.org/artikel/programmiertechnik/liveconnect/
Vllt ist deine Frage in einem Flashforum besser aufgehoben...
Schön, dass wir über jede kleine Änderung auf deinem Desktop informiert werden, LukeGee 🙂
Hi,
man möge mich korrigieren, aber einen solchen Standard gibt es meines Wissens nach nicht. 😉
Speicher' doch einfach als <br />, also als HTML Zeilenumbruch für Webanwendungen, und wenn das vom Windowsclient aufgerufen wird, mache ein Replace und wandle alle <br />'s in \n's um, bevor zu anzeigst.
Hört sich an, als sei der Hashcode des ViewStates nicht korrekt.
Hintergrund: Da der ViewState clientseitig gespeichert wird, kann er theoretisch von bösen Buben manipuliert werden. Um dies zu verhindern, generiert ASP.NET standardmäßig einen Hashcode auf Basis des aktuellen ViewStates, bevor es die Response an den Client jagt. Beim nächsten Postback wird nochmals ein ViewState-Hashcode generiert, und mit dem alten verglichen. Sind beide verschieden, geht ASP.NET davon aus, dass ein Angreifer den ViewState manipuliert hat.
Die dirty solution wäre hier, die Prüfung des ViewStates einfach abzuschalten. Das machst du ganz am Anfang in deinem Markup der jeweiligen Seite:
<%@ Page EnableViewStateMAC="false" %>
Die saubere Lösung ist natürlich herauszufinden, warum der ViewState verfälscht wird 😉
Mir ist das noch nie passiert, auch nicht bei clientseitigem Code, deshalb stehe ich gerade etwas auf dem Schlauch, und weiß die Antwort nicht so recht. Zeig' vllt. mal rebuildDynRows().
Edit: Wenn das Projekt nicht allzu geheim ist, kannst du ja vielleicht eine zumindest abgespeckte Projektmappe hochladen, mit der das Problem nachvollziehbar ist. Dann könnte man das mit dem ViewState nochmal analysieren.
Hi,
beim Auswählen eines Items in der DropDownList passiert erstmal garnichts, sofern nicht AutoPostBack aktiviert wurde (Property). Soll AutoPostBack nicht verwendet werden, muss ein Submit-Button her, den du bestätigen musst, damit das Label den neuen Text erhält.
Also ich habe es nochmal getestet und das funktioniert wunderbar, genau so wie du das geschrieben hast.
Du kannst einfach Validatoren hinzufügen. Das sind Steuerelemente die dazu da sind, um ein Eingabeelement auf Richtigkeit zu prüfen. Dazu kannst du im Designer beim Hinzufügen von Gridview-Spalten die Spalten in Template-Fields umwandeln. Anschließend kannst du über das Smarttag (das ist der kleine Pfeil der angezeigt wird, wenn du im Designer mit der Maus über dein GridView fährst) die Vorlagen bearbeiten. Zum Beispiel das Edit-Template welches dir die Bearbeitungsansicht einer Zeile anzeigt, oder das Insert-Template, welches dir die Einfügeansicht einer Zeile anzeigt. Dort kannst du in die Spalten jeweils deine Validatoren einbetten.
Es braucht kein Putzmittel, um clientseitig Textboxen zu generieren 🙂
Hab' dir mal ne kleine komplett clientseitige Anwendung geschrieben, die das realisiert. Ich gebe zu, nicht ganz sauber, aber es demonstriert, dass clientseitiges Scripting nicht immer gleich Ajax sein muss. Serverseitig ist das über Page.Request auch abrufbar.
<html>
<head>
<title>TextBox</title>
<script type="text/javascript">
// Die Klasse (das Objekt)
function TextBoxGenerator(parent) {
var classHandle = this;
var parentHandle = parent;
this.addTextBox = function(id) {
var txtBox = document.createElement("input");
txtBox.id = id;
parentHandle.appendChild(txtBox);
};
};
// Aufruf
function init() {
var generator = new TextBoxGenerator(document.getElementsByTagName('body')[0]);
generator.addTextBox('tb1');
generator.addTextBox('tb2');
generator.addTextBox('tb3');
generator.addTextBox('tb4');
}
</script>
</head>
<body onload="init();">
</body>
</html>
Hallo,
habe mir auf Vista die Beta 2 des kommenden Visual Studios installiert, und sie mal etwas angetestet. Was haltet ihr von der neuen Umgebung? Ich bin mal so frei und schreibe, was ich so denke. Vielleicht hat sich jmd. die Beta noch nicht angesehen und möchte mal eine Meinung zum Produkt hören:
Also erstmal muss ich sagen, dass man zur Zeit definitiv merkt, dass das Produkt noch nicht stabil ist. Die Installation war die Hölle - während des Setups (in Vista wohlgemerkt) wurde nach dem XP Service Pack 2 gefragt. Nur durch das Ändern von Registry-Einträgen kam ich um diese Prüfung herum. Das .NET Framework 3.5 konnte mit dem Setup überhaupt nicht korrekt installiert werden, die Installation wurde mit einer Exception beendet. Durch manuelles Herunterladen und Einrichten des Frameworks, lief das Setup schließlich durch.
Die Entwicklungsumgebung selbst stürzt oftmals beim Kompilieren v. Projekten ab. Der WPF-Designer zeichnet die grafische Oberfläche meiner XAML Dialoge noch nicht richtig. Manchmal muss man in die Bildfläche klicken, damit alle Steuerelemente korrekt gerendet werden, und nicht nur teilweise.
Soviel zum Beta-Status, ich gehe davon aus, dass Microsoft diese Probleme in den nächsten Monaten noch beseitigen wird.
Was mir sofort positiv aufgefallen ist, ist dass die IDE insgesamt weniger träge wirkt. Mit einem Duo-Core Notebook und 2 GB Ram laufen alle Entwicklungsschritte recht zügig.
Die ASP.NET Entwicklungsumgebung ist ganz großes Kino, das muss ich echt sagen. Der grafische Designer läuft nun bei weitem schneller und stabiler als in Version 2005. Zum Beispiel hatte ich bisher gelegentlich das Problem, dass das Property-Fenster noch auf Steuerelement 1 zeigte, Steuerelement 2 aber bereits markiert war. Wollte ich nun Property-Änderungen an Steuerelement 2 machen, wurden die noch in Steuerelement 1 gespeichert. Dieses Problem ist nun behoben. Angenehm ist auch die geteilte Ansicht zwischen Markup und Design.
Der Javascript-Editor ist klasse, dieses Feature habe ich schon seit Jahren vermisst. Auch der verbesserte CSS Editor ist mir positiv aufgefallen. Ansonsten ist in diesem Bereich nun alles sehr Web 2.0: Der Putzmittelzusatz (Ajax) muss nun also nicht mehr separat geladen werden, sondern ist direkt in der IDE enthalten.
Am meisten hat mich zu Beginn der neue WPF-Editor interessiert. Insgesamt wirkt das Teil noch etwas unstabil, aber man kann bereits gut damit arbeiten. Dass die Windows Presentation Foundation eine tolle Sache ist, ist keine Frage. Der Designer-Support in VS 2008 ist allerdings sehr dürftig. Ich weiß, dass "Expression" der primäre XAML-Editor ist, und VS 2008 hier nur Notwendiges anbietet, aber im Vergleich mit Windows Forms sieht die Designunterstützung für WPF doch recht arm aus.
Per XAML definierte DataTemplates können einem Steuerelement beispielsweise nicht im Property-Window zugewiesen werden, es gibt kein Data-Binding-Per-Mausklick mehr für schnelles Prototyping, wie es in Windows Forms der Fall war (die Datenquellenansicht ist hier nutzlos geworden), und auch sonst scheint man auf das Nötigste beschränkt. Ich habe zwar kein Problem damit, das alles mit XAML zu codieren, aber im Windows Forms-Editor fühle ich mich nach wie vor wohler.
Ansonsten haben wir nun Projekttemplates für Workflowanwendungen und die Windows Communication Foundation. Die Editoren für die WWF sehen sehr leistungsstark, flink und hübsch aus, da ich mich mit WWF aber bisher kaum auseinander gesetzt habe, kann ich hier nicht urteilen.
Das war so das Wichtigste, was mir spontan eingefallen ist.
Was waren eure Erfahrungen?
Dynamisch generierte Controlls gehen verloren, weil deine Pageklasse nach jeder Response wieder zerstört wird, das Los der zustandslosen Verbindung 😉
Dir bleibt also nichts anderes übrig, als alle Controlls bei jedem Request neu zu zeichnen. Dazu nötige Informationen wie die Anzahl der zu generierenden Controlls kannst du entweder clientseitig (im ViewState) oder serverseitig (SessionState) für den jeweil. Benutzer speichern.
Kann es sein, dass Express dieses Feat. nicht bietet?
Hallo,
ich nutze VB.NET Assemblys in Excel 2007, was auch mittlerweile gut klappt. Nun habe ich eine größere Assembly erstellt welche mittels Sockets kommuniziert. Wenn ich diese in Excel VBA aufrufe, kommt nach ein paar Sekunden Verarbeitung die Fehlermeldung "Automatisierungsfehler".
Nun kann ich mit dieser Meldung herzlich wenig anfangen. Deshalb wollte ich fragen, welche Debuggingmöglichkeiten ich eigentlich an dieser Stelle habe. Am liebsten wäre mir ein Singlestep-Debugging wie in Visual Studio, aber ich glaube das kann ich in VB6 vergessen.
Der eine oder andere mag mir nun den Tipp geben, meine Assembly in einer WinForms Anwendung zu testen. Das Problem ist nur: Das habe ich bereits getan, und da funktioniert sie einwandfrei. Der Fehler "Automatisierungsfehler" kommt lediglich, wenn ich die Assembly von Excel aus aufrufe.
Ich hoffe auf Hilfe.
Merci.
Hier finden sich ein paar ganz nette bilduntermalte Artikel.
ASP.NET Formulare kannst du im visuellen Designer grafisch bearbeiten. Wenn du ein Steuerelement, wie in deinem Fall ein Textfeld in die Designer-Ansicht ziehst, wird für deine von Page-Klasse automatisch eine entsprechende Klasseninstanz erstellt, die nach der von dir für das Steuerelement vergebene ID benannt wird. Lange Rede kurzer Sinn, ziehe im Ansichtendesigner eine TextBox auf das Formular. Sie wird standardmäßig mit TextBox1 benannt. Im Code kannst du deine TextBox dann mit TextBox1.Attribut oder TextBox1.Methode() ansprechen.
Bitmap bmp = new Bitmap(320, 200); // Parameter: Breite, Höhe
Graphics g = Graphics.FromImage(bmp);
g.DrawString(...);
Die Parameterreihenfolge von Graphics.DrawString kannst du dir in der MSDN erarbeiten oder durch IntelliSense anzeigen lassen, ich habe sie nicht im Kopf.
Ich denke auch, dass man es mit der Abstraktion durchaus übertreiben kann. Ich wähle ein bestimmtes Datenbanksystem aus, und will auch dessen Vorteile nutzen.
Ich nutze auch SQL Statements im Code, trenne aber Datenzugriff durch eigene Assemblies von der Anwendung ab. Wenn SQL ausgelagert werden soll, dann in Stored Procedures.
Mein Problem ist immernoch nicht gelöst, aber wir haben nun eine neuere Office-Version installiert und da funktioniert es auf Anhieb perfekt. Also das Problem tritt nur mit Office 2000 auf. Nunja, insofern hat sich die Sache erledigt.
Danke für deine Hilfe, Rainbird.
Als Informationsquelle für was?