xsharp.eu

Hi Chris
now I added a reference (like Wolfgang says with right-click) to System.Drawing and placed the USING to another position. A reference to Gma.QrCodeNet.Encoding.dll already is in project. So the errors were reduced to 6.

I'm using XIDE!

I installed the X# Plugin for ILSpy, so I can do a X# look at the code inside my Dll. If I cannot deal with this and it's necessary to get some code from it, I would be glad if I can send you this Dll. This time it's only for learning not for a customer project.

Is it possible to compile and run such a translated C# to X# Dll like the original one? And then make changes in the X# Code? The question is because the vendor no more exists and if the legislator demands changes I could do this by myself instead of throwing it away and implementing a new one in my apps.

Thank you for your answers!

Hi Fabrice
thank you for your example, I will take a look at it!

Hallo Wolfgang,
die doppelte Definition von stream und die Referenz bei FileStream{@.. sind klar. Bei den Fehlern XS0120 bin ich davon ausgegangen, dass qrCode := qrEncoder.Encode("Hello World!") ein Object rückliefert.

Bei deinem Verdacht muss ich dir Recht geben: das liegt daran dass ich bisher allen Produkten von M$ aus dem Weg gegangen bin (mit Ausnahme OS) und hoffe dass ein Befassen damit auch nicht mehr notwendig sein wird. Leider gibt es aber VO Programme von mir, wo eine Einbindung dieser C# Dll notwendig war, weil sich diverse Notwendigkeiten nicht mit VO lösen ließen. Ich hoffe, dass der Gesetzgeber seine Vorgaben an diese Dll nicht ändert, denn dann muss ich mich mit .NET auch nicht befassen.

Hallo Franz,
daß man mittlerweile mit VO an viele Grenzen stößt, ist schon klar, und auch erwartbar - schließlich ist das System als solches bereits mehr als 20 Jahre alt, und auch das Win32-API, auf dem VO fusst, ist schon sehr lange nur mehr im Instandhaltungs-Modus.
Das geht aber bei allen anderen Entwicklungsumgebungen auch nicht anders, siehe Delphi, C++ oder Visual Basic (nicht .NET). So gesehen hält sich VO nicht schlecht.
Wir haben halt den Vorteil, mit X# die Sprache weitgehend beibehalten zu können.
Sobald es aber an die Nutzung von .NET DLLs aus anderen Sprachen geht (die von den Tricks der X#--Entwickler wie dem Ignorieren-Können von Namespaces oder statischen Methoden nichts wissen), dann muss man sich unweigerlich auch mit den Konzepten von .NET befassen.
So im Rückblick war für mich der Plattformwechsel (der dritte in meinem Programmierleben) sicher der herausfordernste, aber IMHO auch der, wo ich am meisten gelernt habe (und immer noch jede Menge zu lernen habe).
Und da ich der Meinung bin, dass Lernen flexibel erhält, plane ich auch gar keinen Abschied davon, solange ich dazu in der Lage bin.
Abgesehen davon denke ich, ich muss im X#-Wiki mal eine leichtverdauliche Zusammenfassung der Konzepte für VO-Programmierer schreiben.....
Wolfgang

Hallo Wolfgang,
mit 3 Plattformwechsel komme ich nicht aus, angefangen habe ich mit Maschinensprache und Assembler auf Computern mit Magnetkonten und 4K Hauptspeicher. Danach CPM, DOS, Unix, VMS, Win mit unterschiedlichen Programmiersprachen und Datenbanken.

Ich hätte mir für mich halt noch eine Verbesserung an VO gewünscht (ohne .NET), da ich nicht mehr viel auf diesem Gebiet mache und sich daher der Umstellungsaufwand für mich nicht rechnet.

Das Problem ist nur, dass ich Programme draußen habe, die eine bestimmte C# DLL einsetzen, weil diese aufgrund der Registrierkassenverordnung gesetzlich notwendig war. Solange der Gesetzgeber nichts ändert und VO noch auf irgendwelchen Win Versionen läuft, muss ich mich mit X# daher nicht befassen. Blöd wirds nur, wenn sich da was ändert, denn die Herstellerfirma dieser DLL existiert nicht mehr und kann also nicht nachbessern und dann muß ich entscheiden:
- die Kunden im Regen stehen lassen, weils Programm nicht mehr einsetzbar ist
- die Programme umbauen auf eine Schnittstelle eines anderen Herstellers und die DLL damit ersetzen
- selber in die DLL eingreifen was wegen C# nicht geht, aber ev. mit X# machbar wäre
LG Franz

Hallo Franz,
als Plattform-Wechsel habe ich "nur" den Sprung vom IBM-kompatiblen Mainframe und Cobol zur DOS-Plattform mit C und Clipper gerechnet, dann den Sprung mit VO nach Windows (samt Objekt-Orientierung und Eventsteuerung), und dann eben den Wechsel nach .NET.
Kleinere Plattformen, mit denen ich mich im auch noch beschäftigt habe, wie HP MPE (Cobol), HP-UX, SCO Unix und Novell Netware (immer C) und ein bisschen HTML und PHP, sowie meine Ausflüge in die System-Administration sind einfach nicht wichtig genug....
Was die Unterstützung Deiner Kunden betrifft, sehe ich halt zwei Möglichkeiten: entweder Du kniest Dich da selber rein, mit der Bereitschaft, Zeit und Energie ins Lernen zu investieren, oder Du lässt Dir da helfen - diesbezüglich ist das X#-Team definitiv auch "bestechlich", d.h. sie machen auch (bezahlte) Projekt-Arbeiten (und das ist definitiv gut investiertes Geld). Aber es gibt auch sonst genügend Leute hier, die Dir ein paar Stunden weiterhelfen können.
Wolfgang

Hallo Wolfgang,
ich schau mir demnächst mal das X# Plugin für ILSpy an. Wenn man damit die DLL wirklich so decompilieren kann, dass ein X# Code rauskommt, den man abändert, neu kompiliert und wieder einsetzen kann, dann wäre das ideal. In dem Fall könnte ich dies dann ja als Auftragsarbeit an das X# Team vergeben, sollte sich gesetzlich was ändern.

Hallo Franz,

lagraf wrote: ich schau mir demnächst mal das X# Plugin für ILSpy an. Wenn man damit die DLL wirklich so decompilieren kann, dass ein X# Code rauskommt, den man abändert, neu kompiliert und wieder einsetzen kann, dann wäre das ideal.

Ohne ausreichende Kenntnisse von .Net/X#/C# würde ich mich darauf nicht verlassen.

Dick

Hallo Wolfgang,
wenn du was schreiben willst: wie wäre es mit einem X# Buch von Hello World langsam hoch bis zu komplexen Lösungen (so eine Art Cookbook)?
LG Franz

Hallo Franz,
da habe ich gleich mehrere Probleme damit:
- ich habe nicht die Qualifikation, ein Buch zu schreiben
- habe ich echt keine Zeit dafür
- gibt es keinen ausreichenden Markt dafür, um auch nur die Kosten reinzuspielen
- habe ich auch nicht genug Fachwissen dafür
Wolfgang