JPEG aus Stream lesen und anzeigen

Noodles

Jockelx schrieb:

Bei dir fehlt
using System.Drawing.Imaging;

Weshalb?
Mein Codebeispiel funktioniert auch ohne diese Anweisung.

schrankwand

@Jockelx: Also erstens geht das sehr wohl was ich da geschrieben hab und zweitens ha er ja System.Drawing.Imaging schon im using.

@Noodles: Wenn man den Namespace Imaging immer mit angibt schon. Aber z.B. ich bevorzuge es alle verwendeten Namespaces ins using zu packen anstatt sie der Klasse immer vorran zu stellen.

Noodles

schrankwand schrieb:

@Noodles: Wenn man den Namespace Imaging mit angibt schon.

Weshalb ich ihn mit angegeben habe.

schrankwand schrieb:

Aber z.B. ich bevorzuge es alle verwendeten Namespaces ins using zu packen anstatt sie der Klasse immer vorran zu stellen.

Ändert nichts an der Tatsache, dass es ohne using ... funktioniert.

@schrankwand:
Hast du einen c#-Kompiler da?
Ich nämlich nicht, kann es daher nicht ausprobieren.
Bin mir aber sicher, dass das so in meinem Buch steht;
hab aber bei MSDN auch nix gefunden, dass das nicht geht.
Also, wenn du das nicht 100% weisst, dann probier es mal bitte aus.

schrankwand

Ja, ich habe einen C#-Compiler da, wobei genau genommen werden .NET-Anwendungen erst zur Laufzeit kompiliert. Rein zufällig bin ich nämlich Programmierer in einem Unternehmen wo in C# programmiert wird. Nichts desto trotz dient die using-Anweiung dazu das ständige angeben von Namespaces zu ersparen. Die using-Anweisung hat also rein garnichts mit der #include-Direktive von C++ zu tun oder womit auch immer du das jetzt verwechselt hast.

schrankwand schrieb:

Ja, ich habe einen C#-Compiler da, wobei genau genommen werden .NET-Anwendungen erst zur Laufzeit kompiliert.Rein zufällig bin ich nämlich Programmierer in einem Unternehmen wo in C# programmiert wird.

Und wann wirst du entlassen?

1. Ich hab dir eine normale Frage gestellt, weil ich selber nicht mehr
sicher war.

2. Kompilieren heisst nicht unbedingt in nativen Code zu übersetzen!
Eine C#-Datei wird natürlich nicht erst zur Laufzeit kompiliert.

Noodles

schrankwand schrieb:

Rein zufällig bin ich nämlich Programmierer in einem Unternehmen wo in C# programmiert wird.

Fehlt nur noch ein Ätsch am Ende des Satzes.
So eine Aussage sagt nichts über die Kenntnisse Deiner Person aus.

schrankwand

@Jockelx: Achja? Und wieso heisst das dann JIT-Compiler - Just-in-Time-Compiler? Außerdem wird nich die C#- sondern die exe-Datei zur Laufzeit kompiliert, genau wie bei Java. Das umwandeln von Quellcode also der C#-Dateien in .NET-Bytecode bezeichnet man allenfalls als Vorkompilieren. Aber wir kommen jetzt langsam vom eigentlichen Thema ab.

Ich hab nie bestritten, dass auch zur Laufzeit kompiliert wird...

Egal, dann kommen wir halt zum Thema zurück:
Das mit dem "hast du einen C#-Kompiler da" war ja nicht böse gemeint,
ich hab halt gerade keinen da und ich wollte das du deine Aussage
nochmal überprüfst. Also kann man ein namespace so aufteilen:

namespace1.namespace2.namespace3.Klasse;
in
using namespace1.namespace2;
...
namespace3.Klasse

Das hast du ja behauptet.
Ich habs selber nie ausprobiert, weiss aber das das laut meinem Buch
nicht erlaubt ist.
Wenn du also lust hast, dann probier es aus damit wir Klarheit haben.
Sonst versuch ich es zuhause.

Jockel

schrankwand schrieb:

Das umwandeln von Quellcode also der C#-Dateien in .NET-Bytecode bezeichnet man allenfalls als Vorkompilieren.

Ich will nicht wieder anfangen, aber das ist Quatsch!

schrankwand

So, ich habs jetzt extra für dich zum 7216. Mal ausprobiert und wer hätte es geahnt ...

namespace Application
{
	class Class
	{
		static void Main()
		{
			System.Console.WriteLine("Hallo");
		}
	}
}

und

using System;

namespace Application
{
	class Class
	{
		static void Main()
		{
			Console.WriteLine("Hallo");
		}
	}
}

geben beide in einem Konsolenfenster das Wort "Hallo" aus ohne das Visual Studio eine Warnung ausgibt oder die Anwendung eine Exception wirft.

Gut, glaub ich dir mal

Nur zur Information, warum ich es gerne getestet haben wollte:
In C# Kompendium, Markt+Technik steht halt (offenbar fälschlicherweise)
drin, dass das nicht geht.

Aber 7216 Gegenbeispiele widerlegen das ja wohl.

Jockel

Noodles

Das ist doch nicht das, was Jockelx gemeint hat, oder?
Console ist eine Klasse und kein Namespace.

namespace1.namespace2.namespace3.Klasse;
in
using namespace1.namespace2;
...
namespace3.Klasse

Hast schon Recht
Wollte schrankwand aber nicht enttäuschen, weil er sonst 7216 Beispiele
umsonst eingetippt hätte. Ich probiers sowieso zuhause aus, es sei denn
du sagst mir jetzt ob ich (bzw. mein Buch) doch Recht hatte.

Jockel

Noodles

Was Du meinst funktioniert nicht.

schrankwand

Hä? Das ist doch genau das was er meinte. Ich habe den Namespace System ins using gepackt damit ich ihn nicht explizit angeben muß. Vom Klassen ins using packen war nie die Rede.

Noodles

schrankwand schrieb:

Hä? Das ist doch genau das was er meinte. Ich habe den Namespace System ins using gepackt damit ich ihn nicht explizit angeben muß. Vom Klassen ins using packen war nie die Rede.

Lies nochmal genau nach und überdenke Jockelx seine Frage.

namespace1.namespace2.namespace3.Klasse;
in
using namespace1.namespace2;
...
namespace3.Klasse

Das musst Du doch verstehen, denn

Rein zufällig bin ich nämlich Programmierer in einem Unternehmen wo in C# programmiert wird.

schrankwand

Ich hab jetzt nur namespace 2 und 3 weggelassen, da ich sonst keine vollständigen Beispielcode hätte in 12 Zeilen schreiben können. Aber man sollte doch schon vom normalen Menschenverstand ableiten können, das es auch funktioniert wenn man noch einen weiteren verschachtelten Namespace ins Using packt und noch einen dritten verschactelten Namespace explizit angibt.

Noodles

Es war so gemeint.

System.Drawing.Imaging.ImageFormat.Jpeg;
// zerlegt in
using System.Drawing;
// und
// (steht in einer Funktion)
Imaging.ImageFormat.Jpeg; // das geht nicht!

schrankwand

Jo, Namespaces muß man immer mit vollständigen Pfad angeben. Ist mir aber eben auch entgangen, da ich sowieso immer alle verwendeten Namespaces ins using packe, kommt sowas bei mir eigentlich nie vor.