Grafikprogrammierung C++ oder C#

[Ben _. (burning_silicon)]

Hat jemand der hier anwesenden sowas schon gemacht und/oder kennt jemand 
ein kleines Tutorial?

[Wanderralle (Gast)]

Hi Ben,
versuchs mal mit Onkel google:

http://www.google.de/#hl=de&tbo=d&sclient=psy-ab&q=grafikprogrammierung+csharp&oq=grafikprogrammierung+csharp&gs_l=hp.3..0i8i30.682435.690511.2.693541.27.16.0.11.11.0.121.1259.15j1.16.0...0.0...1c.1.Wb1UOM-sYmQ&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&bvm=bv.41524429,d.Yms&fp=f0c29644078dfc04&biw=1280&bih=922

Da nicht C# eingeben, sondern csharp.

Oder gib mehr Informationen Preis. Welche IDE, 3D oder einfach auf einer 
Canvas "rumpinseln"?

Wenn du noch nicht weisst welche IDE, dann kuck mal bei wikipedia unter 
csharp.

Gruß
Ralf

P.S.: Weiss nicht ob und wann ich wieder mal hier vorbeistreune...

[Ben _. (burning_silicon)]

3D wollte ich eigentlich nicht, das endet ja mit Spielereien mit der 
Grafikkarte.

Was schön wäre erstmal eine Oberfläche erzeugen zu können auf der ich 
sowas wie Sprites einsetzen kann, oder Grafikbefehle ausprobieren kann 
wenn es sowas unter C++ oder C# gibt.

[Sven B. (scummos)]

Ich schlage einfach mal wieder Qt vor ;)
http://qt-project.org/doc/qt-4.8/graphicsview.html

oder genauer
http://qt-project.org/doc/qt-4.8/qgraphicsscene.html
http://qt-project.org/doc/qt-4.8/QGraphicsView.html

[Ben _. (burning_silicon)]

Sorry, fällt aus wegen ist nicht.

Entweder C++, C# oder eventuell noch Visual Basic.

[Andreas S. (andreas) (Admin)]

Ben _ schrieb:
> Was schön wäre erstmal eine Oberfläche erzeugen zu können auf der ich
> sowas wie Sprites einsetzen kann

http://www.libsdl.org/

[troll (Gast)]

Andreas Schwarz schrieb
> http://www.libsdl.org/
Danke! Das kann ich bestimmt auch mal gebrauchen.

[Ben _. (burning_silicon)]

Hmm... Windows nur 32 Bit?

Ich würd das wie bereits in einem anderen Thread probiert am liebten mit 
was langlebigem versuchen. Deswegen C++, C# oder (ungerne) VB.

Bitte keine neue welche Programmiersprache - Schlacht... :-(

[Sven B. (scummos)]

Ben _ schrieb:
> Sorry, fällt aus wegen ist nicht.
>
> Entweder C++, C# oder eventuell noch Visual Basic.

Ich dachte immer, Qt sei C++... naja ;p

[Ben _. (burning_silicon)]

Ja aber nicht irgendwelche Baukästen, die dann irgendwann nicht 
weiterentwickelt werden. Oder kann die C++ Basis keine Grafik?

[Sven B. (scummos)]

Qt ist kein "Baukasten", sondern ein Framework. Die stdlib ist auch ein 
Framework...

"Die C++-Basis" "kann" keine "Grafik" (was diese Aussage so genau 
bedeuten soll, weiß ich selber nicht, weil die Begriffe alle ziemlich 
undefiniert sind, aber ich denke, es ist klar was gemeint ist).
Kannst du dir natürlich selber schreiben, wenn alle Frameworks böse sind 
-- viel Spaß dabei ;)

Zu C++ gehört streng genommen nur die stdlib, und die kann eigentlich 
gar nichts. In der stdlib ist gerade das drin, was bei anderen Sprachen 
(Java, Python, ...) Bestandteil der Sprache ist, also Containerklassen, 
Sortieralgorithmen, ...
Du musst also immer, wenn du irgendwas machst, außer die dem Programm 
übergebenen Argumente irgendwie durch einen Algorithmus zu schicken und 
auf der Konsole wieder auszugeben, auf irgendeine "externe" Bibliothek 
zurückgreifen. Oder das Ganze von Grund auf neu implementieren, aber das 
ist i.d.R. aufwendig und unsinnig.

[Ben _. (burning_silicon)]

Okay dann mal eine ganz direkte Frage geradeaus.

Wer hat ein Beispiel in C, C++ oder C# oder nur wenns nicht anders geht 
in Visual Basic bzw. Visual C, welches ein einfaches Fenster öffnet und 
darin ein paar Linien oder bunte Kreise zeichnet?

Mein Gott, sowas konnte der KC85 von Hause aus...!

[Sven B. (scummos)]

(Ich spreche immer nur für C/C++, von C# habe ich keine Ahnung, das ist 
was ziemlich anderes als C/C++)

Ganz direkte Antwort: Gibt's nicht. Du musst ja schließlich das System 
fragen, dass es für dich ein Fenster öffnet. Im Fall von Linux / X11 
wäre das also die X11 API. Hier ist ein Beispiel: 
http://rosettacode.org/wiki/Window_creation/X11#C
Die zu benutzen ist aber für die durchschnittliche Anwendung absolut 
nicht zu empfehlen und das tut heutzutage auch niemand mehr wenn es sich 
vermeiden lässt.

Unter anderen Systemen sieht das halt wieder anders aus. Deshalb gibt es 
Frameworks wie Qt, GTK etc. die das ein Stück weit abstrahieren.

Es gibt keine sinnvolle Möglichkeit, mit "reinem" (so wie ich denke 
dass du es dir vorstellst, also komplett ohne Einbinden einer "third 
party"-Bibliothek) C/C++ Kram auf den Bildschirm zu zeichnen. Das ist 
einfach nicht Teil vom Standard. Irgendein externes Tool musst du immer 
zu Hilfe nehmen. Jede andere Sprache macht das natürlich genauso... nur 
sieht man's eventuell nicht so deutlich.

[Johannes E. (cpt_nemo)]

Mit wxWidgets und C++ würde das z.B. so aussehen:

http://wiki.wxwidgets.org/Drawing_on_a_panel_with_a_DC

[Karl H. (kbuchegg)]

Und falls es noch nicht klar geworden ist:
Es hängt damit immer auch vom System ab (zb. Windows) was du alles 
einsetzen kannst.
Die eine Maschine hat nun mal eine Grafikkarte im System, die andere hat 
gar nichts. Die nächste hängt an einem Terminal, welche gerade mal 
Blockgrafik am Zeichensatz hat, die andere hat ein Grafikterminal.

Oft gibt es im Betrienssystem Abstraktionsschichten darüber, die dich 
von den Details befreien, eizelne Pixel setzen zu müssen. Und dann hängt 
es auch vom Betriebssystem ab, ob und was es dir nativ an die Hand gibt.

> Mein Gott, sowas konnte der KC85 von Hause aus...!
Es ist leicht etwas zu unterstützen, wenns nicht universell sein muss. 
Wenn das System aber mit wechselnden Hardwareumgebung klar kommen muss, 
sieht die Sache anders aus.

[Sven B. (scummos)]

Richtig. Der C++-Standard ist halt so entworfen, dass er auch auf einer 
Armbanduhr oder einem Mikrocontroller komplett implementiert werden 
kann. Und dort macht "öffne ein Fenster und zeichne einen Kreis" halt 
überhaupt keinen Sinn. Für solche Dinge muss man deshalb das 
Betriebssystem um Hilfe fragen -- wodurch man sich dann natürlich auf 
einige Plattformen einschränkt. Verwendet man ein gutes Framework, so 
schränkt man sich nur auf die Plattformen ein, wo's das Framework gibt 
-- was in der Regel wesentlich mehr sind, als die mit einem bestimmten 
Betriebssystem und einer bestimmten Grafik-Oberfläche. Deshalb ist die 
Verwendung eines Frameworks empfehlenswert.

[Ben _. (burning_silicon)]

> öffne ein Fenster und zeichne einen Kreis
Ich wette das galt vor 10 Jahren auch noch für Handys...

Und mir gehts nach wie vor um einen Desktop-PC für Windows. Der hat 
heute auch immer genug Grafikleistung für sowas. Es sollte mit dem 
möglich sein was Windows von Hause aus mitbringt. Oder brauche ich für 
ein einfaches 2D-Fenster sofort DirectX oder OpenGL?

Ich will das nicht auf Terminals, µCs, nicht auf Armbanduhren und auch 
nicht auf Marsrobotern laufen lassen ... sondern nur auf einem der 
vielen Millionen Windows-PCs mit halbwegs aktuellem Betriebssystem. 
Linux will ich ebenfalls nicht.

[Borislav B. (boris_b)]

Dann mach's doch mit GDI+. Einfacher gehts nicht, braucht auch kein 
extra Framework...

[Karl H. (kbuchegg)]

Ben _ schrieb:
>> öffne ein Fenster und zeichne einen Kreis
> Ich wette das galt vor 10 Jahren auch noch für Handys...
>
> Und mir gehts nach wie vor um einen Desktop-PC für Windows.

Dann sag das gleich und keiner redet aneinander vorbei.
GDI+ ist deine von Windows direkt angebotene API.
Aber selbst dann würde ich an deiner Stelle eher auf C# setzen.
Denn in reinem C++ kommst du um den Teil "erst mal brauch ich ein 
Fenster" nicht drumherum.

[Uwe (Gast)]

Kann dir auch nur die WInAPI vorschlagen. Und wenn du die Schnautze voll 
hast nimm nen Framework. Kommt halt noch drauf an was du machen wilst. 
Für Bildverarbeitung und erkennung kannst du auch OpenCV benutzen. Wenn 
du Diagramme Plotten willst gibt es auch genug. Für GUI ist es gut wenn 
es unter möglichst vielen Betriebssystemen verfügbar ist wie z.B. Qt.
http://de.wikipedia.org/wiki/Liste_von_GUI-Bibliotheken

[Sven B. (scummos)]

Boris B. schrieb:
> braucht auch kein extra Framework...
Naja, abgesehen von GDI+ halt. ;p
Ich hab das zum Beispiel nicht!

Aber ja, wenn das unbedingt nur auf Windows laufen darf und keine extra 
Libs benötigen soll, bleibt die Windows-API. Statisch gegen ein 
vernünftiges Framework linken wäre aber sicherlich die bessere Wahl.

[Ben _. (burning_silicon)]

Ok... wer hat ein Beispiel in C#? Oder VB/VC?

[Borislav B. (boris_b)]

Ben _ schrieb:
> Ok... wer hat ein Beispiel in C#? Oder VB/VC?

Google!

Sven B. schrieb:
> Naja, abgesehen von GDI+ halt. ;p
> Ich hab das zum Beispiel nicht!

Benutzt du Linux oder was? ;-)
Ab Windows XP ist es im Betriebssystem integriert...

[Sven B. (scummos)]

Boris B. schrieb
> Benutzt du Linux oder was? ;-)
Darauf wollte ich hinaus, ja -- funktioniert dann halt nur auf Windows. 
;)

[Borislav B. (boris_b)]

Sven B. schrieb:
> Darauf wollte ich hinaus, ja -- funktioniert dann halt nur auf Windows.

Dem Thread-Starter ging es ja auch explizit um Windows:

Ben _ schrieb:
> nur auf einem der
> vielen Millionen Windows-PCs mit halbwegs aktuellem Betriebssystem.
> Linux will ich ebenfalls nicht.

[Arc N. (arc)]

Ben _ schrieb:
> Ok... wer hat ein Beispiel in C#? Oder VB/VC?

// WinForms / GDI+ wrapper

Pen aPen = new Pen(Color.Red);

void OnPaint(PaintEventArgs e) {
    ...
    e.Graphics.DrawLine(aPen, x1, y1, x2, y2);
}

http://msdn.microsoft.com/en-us/library/4cy2c290(v=vs.110).aspx

[Karl H. (kbuchegg)]

Sven B. schrieb:
> Boris B. schrieb
>> Benutzt du Linux oder was? ;-)
> Darauf wollte ich hinaus, ja -- funktioniert dann halt nur auf Windows.
> ;)

So wies aussieht, scheint ihn das ohnehin schon genug zu beschäftigen.

Ben__
Google dir ein GDI+ Tutorial.
Mit einem Beispiel alleine ist das nicht getan :-)
Über so ein Thema werden ganze Bücher geschrieben. Dicke Bücher!

[Ben _. (burning_silicon)]

Ja daß es da sicherlich hunderte Bücher gibt ist mir klar...

Aber ich hoffe hier hat irgendwer ein paar Codeschnipsel, die ich 
aneineranderreihen kann und irgendwas Compilierbares rauskriege, was in 
seinem Ablaufen zu verstehen und erweiterbar ist. Also wie kriegt man es 
vielleicht hin, den entstandenen Kreis anzuklicken, wie kriegt man ein 
Button mit irgendeiner Funktion drunter ... Schritt für Schritt halt.

[D. I. (Gast)]

Ben _ schrieb:
> Ja daß es da sicherlich hunderte Bücher gibt ist mir klar...
>
> Aber ich hoffe hier hat irgendwer ein paar Codeschnipsel, die ich
> aneineranderreihen kann und irgendwas Compilierbares rauskriege, was in
> seinem Ablaufen zu verstehen und erweiterbar ist. Also wie kriegt man es
> vielleicht hin, den entstandenen Kreis anzuklicken, wie kriegt man ein
> Button mit irgendeiner Funktion drunter ... Schritt für Schritt halt.

Unter C# am einfachsten mit der WPF meiner Meinung nach:

http://openbook.galileocomputing.de/visual_csharp_2010/visual_csharp_2010_17_001.htm#mj00a08631028b74f88242434e41371c18

http://openbook.galileocomputing.de/visual_csharp_2010/visual_csharp_2010_17_004.htm

[GDI+ (Gast)]

Ben _ schrieb:
> Ok... wer hat ein Beispiel in C#? Oder VB/VC?

In diesem Forum ist Linux die Nr. 1, hier wirst Du immer Qt und 
wxWidgets vorgeschlagen bekommen. Wenn Du unter Windows programmieren 
möchtest, dann schau mal bei http://www.codeproject.com/ vorbei. Hier 
bekommst Du alles.
z.B. http://www.codeproject.com/KB/GDI-plus/

Eine IDE gibt es bei MS, probiere alles aus und mach was Dir Spaß macht.

[Grüne - Nein danke (Gast)]

GDI+ schrieb
> In diesem Forum ist Linux die Nr. 1,

Auch wenn wir nicht zur Gruppe der elitären Linuxer gehören...Hier mal 
ein Beispiel für Menschen, die dem Moloch Microsoft hörig sind:

Das Beispiel ist für WPF:

XAML:

Window x:Class="Kreis.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation";
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml";
        Title="MainWindow" Height="350" Width="525">
    <Canvas Name="C">
        <Ellipse Name="el1" Height="168" Stroke="Black" Width="70" 
MouseLeftButtonDown="el1_MouseLeftButtonDown" 
MouseLeftButtonUp="el1_MouseLeftButtonUp" MouseMove="el1_MouseMove" 
Canvas.Left="0" Canvas.Top="0" Fill="Black"/>
    </Canvas>
</Window>

Code behind:

using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;

namespace Kreis
{
    public partial class MainWindow : Window
    {
        private bool cap;
        private UIElement quelle;
        private double xc;
        private double xs;
        private double yc;
        private double ys;

        public MainWindow()
        {
            InitializeComponent();
        }

        private void el1_MouseLeftButtonDown(object sender, 
MouseButtonEventArgs e)
        {
            quelle = (UIElement) sender;
            Mouse.Capture(quelle);
            cap = true;
            xs = Canvas.GetLeft(quelle);
            xc = e.GetPosition(C).X;
            ys = Canvas.GetTop(quelle);
            yc = e.GetPosition(C).Y;
        }

        private void el1_MouseMove(object sender, MouseEventArgs e)
        {
            if (cap)
            {
                double x = e.GetPosition(C).X;
                double y = e.GetPosition(C).Y;
                xs += x - xc;
                Canvas.SetLeft(quelle, xs);
                xc = x;
                ys += y - yc;
                Canvas.SetTop(quelle, ys);
                yc = y;
            }
        }

        private void el1_MouseLeftButtonUp(object sender, 
MouseButtonEventArgs e)
        {
            Mouse.Capture(null);
            cap = false;
        }
    }
}

[Grüne - Nein danke (Gast)]

Hier die Funktion. Sry an alle Linuxer, dass ich "wmv" verwendet habe.

[D2D (Gast)]

Für schnelle 2D Grafik- und Textausgabe unter Windows benutzt man 
Direct2D, DirectWrite und WIC. GDI+ war eine blödsinnige Entwicklung 
weil es keine Hardware-Beschleunigung der Grafikkarte benutzt.

[Grüne - Nein danke (Gast)]

D2D schrieb:
> Für schnelle 2D Grafik- und Textausgabe unter Windows benutzt man
> Direct2D, DirectWrite und WIC. GDI+ war eine blödsinnige Entwicklung
> weil es keine Hardware-Beschleunigung der Grafikkarte benutzt.

Stimmt. Und Nachts ist es kälter als draussen.

[Johannes E. (cpt_nemo)]

GDI+ ist, wenn ich das richtig verstanden habe, zum Zeichnen geeignet. 
Es gibt dort aber keine Funktionen, um z.B. mit der Maus etwas 
"anzuklicken".

Da sind die Frameworks (qt, wx) wesentlich besser geeignet.

[Karl H. (kbuchegg)]

Johannes E. schrieb:
> GDI+ ist, wenn ich das richtig verstanden habe, zum Zeichnen geeignet.
> Es gibt dort aber keine Funktionen, um z.B. mit der Maus etwas
> "anzuklicken".

Nachdem 'anzuklicken' sowieso für jeden was anderes bedeutet, ist das 
kein Beinbruch. In einem CAD wird eine Linie 'angeklickt', indem man 
einen Fangbereich rund um die Linie legt. Liegen mehrere Dinge 
übereinander, dann kann es sein, dass dein Programm den Benutzer fragen 
will, welches gemeint ist. Wie ist das bei Texten? Muss man genau in den 
Buchstaben treffen, kann man zwischen den Buchstaben durch auf die 
dahinterliegende Fläche klicken oder geht das nicht? Wie ist das, wenn 
gezoomt ist? Vielleicht sind auch diverse Dinge überhaupt vom anklicken 
ausgenommen?
Womit wird eigentlich geklickt? Im CAD ist es gar nicht so unüblich, 
dass es neben dem Mauszeiger noch einen künstlichen Cursor gibt, der 
zwar im Regelfall mit der Mausposition identisch ist, der aber auch 
davon abweichen kann und sich zb an diverse zeichnerisch spezielle 
'Punkte' in der näheren Umgebung der Maus einklinkt. Den Schnittpunkt 
2-er Linien werde ich nämlich mit der Maus nicht exakt treffen. Ein 
Cursor, der auf diesen Punkt einsnappt und in der Geometriedatenbasis 
nach derartigen Punkten in der Umgebung sucht, und sich dann dort hin 
stellt, aber schon. Wenn wir schon dabei sind: nehem ich ein 
geometrisches Primitiv mit der Maus auf, zum Beispeil eine Linie, und 
verschiebe ich die, dann sollte die zum Bleistift dann ebenfalls dieses 
Verhalten kurzfristig erben und mit ihren Endpunkten an 'speziellen 
anderen Punkten' in der Nähe einsnappen. Denn händisch und nur mit der 
Maus kriegst du das nicht 100% hin.
Was ist mit einem Raster, welches mir die Cursor-Positionen zusätzlich 
manipuliert. Wie nahe muss die Maus an einem Rasterschnittpunkt liegen, 
damit der Cursor entsprechend modifiziert wird?


Da gibt es viele Dinge, die dir auch deine Frameworks nicht regeln. 
Letzten Endes ist die Welt der Computer-Grafik ein wenig umfangreicher 
als 'ziehe eine Linie von A nach B oder male eine Kreis und fülle ihn 
mit der Farbe aus'.

[Uwe (Gast)]

Schnell mal ... geht da nichts ohne sich mindestens 200-500 Seiten mit 
der WinAPI beschäftigt zu haben und sich ständig beim programmieren die 
MSDN Library als Referenz anzugucken.

[Christian B. (casandro)]

Wenn es mal eben schnell eine beeindruckende Visualisierung sein soll, 
dafür gibts "InfoBeamer". Das ist ein Lua Framework.

http://www.youtube.com/watch?v=Jl_nNo6yUQc
http://www.youtube.com/watch?v=LMHMV3hlTLk

Das ganze geht mit extrem wenig Aufwand.

[Karl H. (kbuchegg)]

Uwe schrieb:
> Schnell mal ... geht da nichts ohne sich mindestens 200-500 Seiten mit
> der WinAPI beschäftigt zu haben und sich ständig beim programmieren die
> MSDN Library als Referenz anzugucken.

wenns anders wäre, würden ganz viele Leute ganz viel falsch machen, in 
dem sie jahrelang gelernt haben, was sich andere anhand von 3 
Codebeispielen in einer halben Stunde beigebracht haben.

PS:
Ein Schachprogramm sieht auch in C NICHT so aus

#include <stdio.h>

int main()
{
  play( "Chess" );
}

[Ben _. (burning_silicon)]

Du mußt nur die richtige Schachbibliothek includen... ;)

Aber um mal bei dem Beispiel zu bleiben - wie malt so ein Schachprogramm 
sein Spielfeld und die Figuren in sein Fenster?

[Sven B. (scummos)]

Indem es Linien und Kreise zeichnet oder auch vorgefertige Bilder auf 
dem Bildschirm anzeigt, an bestimmten Stellen.

[Ben _. (burning_silicon)]

Gut, so schlau bin ich alleine. Mich interessiert die technische 
Umsetzung, nicht das Offensichtliche.

[Sven B. (scummos)]

Dann wäre es hilfreich, das genaue Framework und die Programmiersprache 
anzugeben, in der dich das interessiert. Für "Schach-Spielfeld zeichnen 
in C/C++/C#/VB" fallen mir ungefähr 5000 Möglichkeiten ein, die alle 
total unterschiedlich aussehen.

[Ben _. (burning_silicon)]

Eine reicht mir.

Eine Sprache, die sich für sowas eignet und nicht auf etliche Zusätze 
angewiesen ist. Ich möchte das nur ungerne neu aufkochen, ich würd gerne 
was nutzen, was ich einmal installiere und gut, wo ich evtl. auch 
Bibliotheken für 3D oder Audio zu finde WENN ich sowas machen brauchen 
sollte. Ich kann diese Sprachen alle gleich schlecht, weiß auch auf 
diesem Wege keinen Favoriten.

Meine Favoriten immer noch C++ oder C#. Aber ohne extravagante Zusätze.
Ist schwer sich auf eine festzulegen wenn man noch nicht weiß was sie 
können.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Ich bin mir nicht sicher, wo du hinwillst, aber M$ VisualC++ Express 
2010  und das DirectX SDK kosten nichts und speziell das DirectX SDK 
enthält eine Menge Beispiele für Grafikprogrammierung unter Windows und 
XBox. Der Hauptfokus liegt dabei zwar auf 3D, aber einige Beispiele 
benutzen auch nur 2D.
Soweit ich weiss, gibt auch für VC++ ohne DirectX ein Beispielpaket, das 
ich aber nicht runtergeladen habe, weil ich es hier nicht brauchte.
Einige Source Code für 2D/3D Grafik habe ich noch für den alten Code 
Warrior von Metrowerks, aber das ist wirklich obsolet (obwohl die 
Programme sogar noch auf Win64 laufen). Bei Interesse sag es.

[Mark B. (markbrandis)]

Ben _ schrieb:
> Eine Sprache, die sich für sowas eignet und nicht auf etliche Zusätze
> angewiesen ist.

Dann kommt auch Java definitiv in Betracht. Wer C++ kann, kommt nach 
einer kurzen Einarbeitung auch mit Java zurecht.

Ein Vorteil von Java ist, dass in den Klassenbibliotheken von Haus aus 
sehr vieles schon mit dabei ist, was man in anderen Sprachen durch 
zusätzliche Libraries "nachrüsten" muss.

Beispiel für Rechteck zeichnen:
http://www.java2s.com/Tutorial/Java/0261__2D-Graphics/DrawRectangle.htm

[Al3ko -. (al3ko)]

Sven B. schrieb:
> Indem es Linien und Kreise zeichnet oder auch vorgefertige Bilder auf
> dem Bildschirm anzeigt, an bestimmten Stellen.

:D

[Sven B. (scummos)]

Ben _ schrieb:
> Meine Favoriten immer noch C++ oder C#. Aber ohne extravagante Zusätze.
Ist halt irgendwie schwierig, weil C++ "von Haus aus" eigentlich gar nix 
kann, und du zwar jede Menge Features (GUI, Canvas, 3D, Audio) 
verlangst, aber jedes Framework, welches diese zur Verfügung stellt, als 
"extravagant" bezeichnest. ;p

Schau dir mal Python an, mit dem Standard-Framework gehen die meisten 
von dir verlangten Sachen schon.

[Karl (Gast)]

Es geht nicht ohne Framework. Besonders wenn du alle Sprachen  gleich 
schlecht kannst. Zusätze brauchst du immer. Z.B. Bertriebssystem, 
Grafiktreiber ...

[Andreas H. (ahz)]

Ben _ schrieb:
> Ok... wer hat ein Beispiel in C#? Oder VB/VC?

Wenn Du VC# oder VC++ hast, dann schau mal bei den Demo Programmen rein.
Ansonsten auf der MSDN Website.

OMG, da ist ja mein Entchen dynamischer ....

/leave@thread

[Ben _. (burning_silicon)]

Andreas, wer hat Dich denn gezwungen mir zu helfen? Tschuldigung...

Mit der Aussage, daß ich alle diese Sprachen gleich schlecht kann wollte 
ich sagen, daß ich eine davon auf jeden Fall lernen muß. Ich kann nur 
keine auswählen weil ich nach wie vor nicht erkennen kann, welche für 
mein Vorhaben am besten geeignet ist.

Wie überredet man denn C++, daß es mehr kann als nichts? Muß man sich 
dafür noch irgendwelchen Kram runterladen (falls ja, ist der kostenlos 
verfügbar?) oder wie geht das?

Wenn Framework dann nur .net.

Ach ja und kein Java oder Phyton oder Pascal oder sonstwas bitte... Nur 
C++, C#, oder wenns nicht anders geht irgendeine Visual-Variante. Muß 
ich mal schauen wo da eigentlich die Unterschiede zur 
nicht-Visual-Variante sind.

[Sven B. (scummos)]

Ben _ schrieb:
> Wie überredet man denn C++, daß es mehr kann als nichts? Muß man sich
> dafür noch irgendwelchen Kram runterladen (falls ja, ist der kostenlos
> verfügbar?) oder wie geht das?
Man benutzt ein f*cking Framework! Mann!

Sorry, aber das sollte doch langsam wirklich klar geworden sein, oder? 
;)

[Arc N. (arc)]

Ben _ schrieb:
> Wenn Framework dann nur .net.
>
> Ach ja und kein Java oder Phyton oder Pascal oder sonstwas bitte... Nur
> C++, C#, oder wenns nicht anders geht irgendeine Visual-Variante. Muß
> ich mal schauen wo da eigentlich die Unterschiede zur
> nicht-Visual-Variante sind.

Dann stehen oben schon die Stichwörter: WPF, XAML, WinForms
WPF/XAML ist das modernere, flexiblere Framework mit u.U. steilerer 
Lernkuve.
Mittlerweile auch die Grundlage für Windows 8 und Windows Phone Apps.

Einleitung von MS
http://msdn.microsoft.com/en-us/library/aa970268.aspx
Andere Einleitungen z.B.
http://wpftutorial.net/
http://www.codeproject.com/Articles/140611/WPF-Tutorial-Beginning

Tools: VS 2012 Express Desktop
http://www.microsoft.com/visualstudio/eng/downloads#d-express-windows-desktop

[Karl H. (kbuchegg)]

Ben _ schrieb:
> Gut, so schlau bin ich alleine. Mich interessiert die technische
> Umsetzung, nicht das Offensichtliche.

for( y = 0; y < 8; ++y )
{
  for( x = 0; x < 8; ++x )
  {
    if( x%2 == y%2 )
      e.graphics.FillRectangle( whiteBrush, x*50, y*50, 50, 50 );
    else
      e.graphics.FillRectangle( blackBrush, x*50, y*50, 50, 50 );
  }
}


zufrieden?

> wenn man noch nicht weiß was sie
können.

Es ist völlig wurscht. Um Lernen kommst du sowieso nicht rum.

[Ben _. (burning_silicon)]

Das sieht auf jeden Fall leicht verständlich aus. Wie PHP.
So jetzt ganz blöde Frage: Welcher Sprache entspricht das?? Oder 
speziell die Frage an Karl Heinz: Welche Sprache würdest Du vorschlagen?

[D. I. (Gast)]

WPF ist XAML. XAML ist eine Auszeichnungssprache in Anlehnung an XML mit 
der man flexibel die grafische Oberfläche beschreiben kann die man dann 
mit C# mit Leben füllen kann. IMO ein wirklicher Fortschritt im 
Vergleich zu WinForms.

[Ben _. (burning_silicon)]

Hrm okay. Muss man diesen XML-Teil verwenden oder ist der optional?

Kann C# sowas wie Grafiken einfügen oder vielleicht sogar sowas wie 
richtige Sprites? Brauche ich im Moment nicht, aber könnte später 
nützlich werden.

[D. I. (Gast)]

Ben _ schrieb:
> optional

optional, alles was man mit dem XML-Teil machen kann, kann man 1:1 in C# 
als Code umsetzen, sieh dir dazu die Links an die ich gepostet hab zum 
Openbook von C#. Und schon nach dem ersten eigenen Ausprobieren wirst du 
merken warum man NICHT mehr alles manuell in Code gießen will. Und das 
trifft auf die meisten Grafiksachen zu. Aber ich denke mit C# + WPF 
kommt man als Einsteiger ziemlich schnell zu ansehnlichen Ergebnissen. 
C++ + Qt ist zwar quasi die eierlegende Wollmilchsau, aber welcher 
Sadist macht denn freiwillig C++ ;)
Und ja, das was du beschreibst geht in C# auch ziemlich geschmeidig, 
konsultier dazu das Kapitel 2D-Grafik

[Sven B. (scummos)]

Muss man natürlich nicht, weil dich keiner zwingt das Framework zu 
benutzen was das zur Verfügung stellt.

Jede Sprache kann (mit der entsprechenden Bibliothek) ein Bild laden... 
außer Brainf*ck vielleicht...

Ich würde vorschlagen, du fängst einfach mal an, irgendwas zu machen 
anstatt soviel rumzuplanen -- das führt zu nix ;p

Grüße,
Sven

[D. I. (Gast)]

Sven B. schrieb:
> Ich würde vorschlagen, du fängst einfach mal an, irgendwas zu machen
> anstatt soviel rumzuplanen -- das führt zu nix ;p

Ein sehr guter Hinweis in diesem Fall.

[Wursti (Gast)]

Ben _ schrieb:
> Hrm okay. Muss man diesen XML-Teil verwenden oder ist der optional?
>
> Kann C# sowas wie Grafiken einfügen oder vielleicht sogar sowas wie
> richtige Sprites? Brauche ich im Moment nicht, aber könnte später
> nützlich werden.

Lieber Ben, ich glaube du bringst da einiges durcheinander. Die Sprache 
hat eigentlich nichts mit der Funktionalität zu tun. Dafür ist nämlich 
das Framework zuständig. OpenGL z.B. Kannst du mit so ziemlich jeder 
Sprache benutzen.

Eine Einschränkung ist natürlich, dass du nicht jedes Framework mit 
jeder Sprache benutzen kannst. Qt mit c# oder Python mit DirectX ist so 
z.B eher schwierig/unüblich.

Wenn du uns mal genauer sagen könntest was du vor hast, könnte man dir 
sicher besser helfen...

[Wanderralle (Gast)]

Hi Ben,

so wie ich dich verstehe willst du geometrische Objekte zeichnen die mit 
der Maus angeklickt werden können und dann ein Ereignis auslösen das vom 
Programm irgendwie weiter verwurstet wird. -Hört sich g*il an. Sag mir 
bescheid wenn du was gefunden hast. Kann ich auch brauchen! ;-)

Hier wirst du aber wohl nicht fündig, da uController andere Aufgaben 
haben und nicht mit vc# oder vc++ programmiert werden.

Frag doch mal in einem C#-Forum. Entweder im Web oder im Usenet. -Ich 
empfehle das Usenet bzw Newsgroups(siehe Wikipedia). MS hat ein paar 
brauchbare Newsgroups für c#, c++ und dotNet.

Evtl gibt es da oder dort irgendwelche Klassen für vc# oder vc++ als 
Freeware oder weiterführende Infos.

Viel Erfolg für den Einstieg in die Programmierung.

Kleiner Tip: möchtest du eine Programmiersprache lernen die dir oder die 
anderen weiterhilft und liegt? -Kuck dir an was welche Sprache kann und 
entscheide dich dann.

Aloahe
Ralf

[Wanderralle (Gast)]

Wanderralle schrieb:
> Hier wirst du aber wohl nicht fündig, da uController andere Aufgaben
> haben und nicht mit vc# oder vc++ programmiert werden.

Wobei die Antworten der letzten halben Stunde schon passen... 
schulterzuck

[Sven B. (scummos)]

> Hier wirst du aber wohl nicht fündig
Sorry, aber wer so sucht wird nie fündig -- es wurden doch schon etwa 15 
funktionierende Lösungen genannt, die aber alle aus irgendeinem nicht 
näher spezifizierten Grund nicht genehm sind ;)

[Sam P. (Gast)]

Wenn es in C++ eh keinen standardisierten Weg gibt, GUI zu machen, warum 
nimmt man dann nicht das ausgereifteste, was die Welt hergibt?


Ben _ schrieb:
> Ich würd das wie bereits in einem anderen Thread probiert am liebten mit
> was langlebigem versuchen. Deswegen C++, C# oder (ungerne) VB.

In dem Fall mach einen Bogen um die "Windows API of the Day". MS hat 
schon so viele API-Säue durchs Dorf getrieben, dass dein erlerntes 
Wissen in 2 Jahren wieder veraltet ist. Schau dir nur mal an, was 
Microsoft in den letzten 10 Jahren alles als "die neue, moderne API" 
angepriesen hat.

Du möchtest es nicht hören, aber Qt existiert seit 20 Jahren, länger als 
die ganze Win32-Welt. Einzig GDI kommt dem nahe, ist aber kein C++ 
sondern reines C. Und wenn du irgendwann auch mal was nicht-triviales 
fertig haben willst, würde ich von sochen low-level APIs Abstand nehmen.

Wenn du hingegen keine Programme für Endanwender schreiben willst und 
tatsächlich nur mit Low-Level-Grafik experimentieren willst, ist GDI 
unter Windows definitiv dein Ding, denn das ist eben die grundlegende 
API, auf der alle anderen aufsetzen. Man muss sich entscheiden, was man 
eigentlich am Ende erreichen will.

[Ben _. (burning_silicon)]

OpenGL sehe ich eigentlich wie Hardware. Sag dem Ding was es machen soll 
und das macht es dann schon. Sowas möchte ich dann anfangen wenn ich es 
brauche. Im Moment wäre das aber zuviel des Guten.

Im Prinzip mag ich keine "zu schnellen" Editoren, wo man auch schnell 
entsprechend viel versauen kann. Da verschiebt sich dann plötzlich die 
komplette Seite weil irgendwas per Definition nicht überlappen darf und 
nach weiteren drei Stunden Korrekturversuchen entscheidet man sich dann 
doch frustriert für's Backup. Geht zB. bei HTML mit verschachtelten 
Tabellen ganz schnell.

Na gut werd mal ein wenig damit rumspielen.

Das Witzige ist - wenn ich es elementar auf einem µC mit 
selbstangebundenem Display oder so machen wollte, dann wüßte ich wie, 
auch wenn's in Assembler vielleicht ein wenig länger dauert. 
Inline-Assembler wäre nett gewesen (In C++ vielleicht noch möglich), 
aber was nicht nicht, geht halt nicht.

[Peter II (Gast)]

Sam P. schrieb:
> In dem Fall mach einen Bogen um die "Windows API of the Day". MS hat
> schon so viele API-Säue durchs Dorf getrieben, dass dein erlerntes
> Wissen in 2 Jahren wieder veraltet ist. Schau dir nur mal an, was
> Microsoft in den letzten 10 Jahren alles als "die neue, moderne API"
> angepriesen hat.

soetwas nennt sich Entwiklung und Anpassen an neue Anforderungen.

Wenn sich seit 10Jahre nichts geändert hat bei QT, dann ist das mehr ein 
zeichen dafür das sie auf krampf versuchen nichts zu ändern nur um 
kompatibel zu sein.

Dann ist es mir doch lieber, wenn man etwas neues versucht um damit alte 
Fehler loszuwerden.

Kann ich denn mit QT mal schnell ein Weboberfläche mit den geleichen 
code erzeugen?

[Sven B. (scummos)]

Peter II schrieb:
> Wenn sich seit 10Jahre nichts geändert hat bei QT, dann ist das mehr ein
> zeichen dafür das sie auf krampf versuchen nichts zu ändern nur um
> kompatibel zu sein.
Nee, ist nicht so. Qt3 und Qt4 sind sogar ziemlich krass inkompatibel 
zueinander. Qt4 und Qt5 sind auch nicht ganz quellkompatibel, aber es 
sind nur kleine Änderungen nötig, die großteils sogar automatisiert 
vorgenommen werden können (so ähnlich wie Python2 -> Python3). Aber Qt3 
-> Qt4 war eine riesige Änderung.

> Kann ich denn mit QT mal schnell ein Weboberfläche mit den geleichen
> code erzeugen?
Ja: 
http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos
Allerdings ein bisschen beta ;)

Grüße,
Sven

[Karl H. (kbuchegg)]

Sam P. schrieb:
> Wenn es in C++ eh keinen standardisierten Weg gibt, GUI zu machen, warum
> nimmt man dann nicht das ausgereifteste, was die Welt hergibt?

Weil das meistens die umfangreichsten Frameworks mit den meisten 
Möglichkeiten sind.


> In dem Fall mach einen Bogen um die "Windows API of the Day". MS hat
> schon so viele API-Säue durchs Dorf getrieben, dass dein erlerntes
> Wissen in 2 Jahren wieder veraltet ist. Schau dir nur mal an, was
> Microsoft in den letzten 10 Jahren alles als "die neue, moderne API"
> angepriesen hat.

Ich seh das so.
Klar gibt es immer wieder mal was neues. Aber als Entwickler muss man 
mal irgendwo anfangen. Und das, was wir vor 25 Jahren in Windows gemacht 
haben, ist heute immer noch nicht obsolet. So manches funktioniert ein 
wenig anders, die Möglichkeiten sind größer geworden, die 
Abstarktionsschichten besser geworden, aber das Grundprinzip ist immer 
noch das gleiche. Und das, was wir damals gelernt haben, ist auch heute 
noch nützlich.

Wer nie anfängt und nie den Sprung ins kalte Wasser wagt, wird auch nie 
weiter kommen. Bei der ersten Programmiersprache ist es auch nicht so 
wichtig, welche es ist, hauptsache man fängt überhaupt mal an. Die 
Prinzipien, die Algorithmen, die ganze Denkweise, das alles sind Dinge 
die nie obsolet werden.


Und für die ersten Schritte in die Grafikwelt gilt genau das gleiche. 
<v<on welcher Programmiersprache aus die gemacht werden, ist ziemlich 
egal. Eine Linie auf dem Bildischirm ist eine Linie. Viele Linien sind 
ein Polygon. Und das kann man füllen. Die syntaktischen Feinheiten und 
wie man einen Brush oder Pen auswählt, um die Füllung bzw. Umrandung zu 
bestimmen ... das sind syntaktische Feinheiten der Sprache oder des 
Franeworks. Aber ein Rechteck sieht in im wesentlichen in der einen 
Sprache genauso aus wie in jeder anderen Sprache auch.

Das, wo einem ein Framework tatsächlich enorm unterstützen kann, dass 
ist die Anbindung ans Betriebssystem. Da gibt es viele verschiedene 
Abstraktionen. Aber die Prinzipien nach denen man komplexe Geometrien 
aus einfachen Teilen zusammensetzt, daran ändert sich nichts.

[Sven B. (scummos)]

Ich stimme Karl Heinz im Prinzip zu. Solange man nicht ein absolut 
bescheuertes Framework / Sprache wählt, ist es relativ egal womit man 
lernt. Die ersten paar Programme werden sowieso "unmaintainable crap" 
sein, egal in welcher Sprache und mit welchem Framework die geschrieben 
sind. Und mit ein bisschen eigener Erfahrung kann man halt auch viel 
besser beurteilen, welche Sprache man jetzt wirklich verwenden will.

[Arc N. (arc)]

Sam P. schrieb:
> In dem Fall mach einen Bogen um die "Windows API of the Day". MS hat
> schon so viele API-Säue durchs Dorf getrieben, dass dein erlerntes
> Wissen in 2 Jahren wieder veraltet ist. Schau dir nur mal an, was
> Microsoft in den letzten 10 Jahren alles als "die neue, moderne API"
> angepriesen hat.

Silverlight -> XAML
Silverlight for Windows Embedded -> XAML
WPF -> XAML
Windows Store Apps -> XAML und HTML
Windows Phone -> XAML

XAML ist ein XML-Ableger, ebenso wie XUL (Mozilla), JavaFX oder XHTML
Allen ist wiederum gemeinsam, dass sie deklarative Beschreibungssprachen 
sind, ebenso wie bspw. QML.

> Du möchtest es nicht hören, aber Qt existiert seit 20 Jahren, länger als
> die ganze Win32-Welt. Einzig GDI kommt dem nahe, ist aber kein C++
> sondern reines C. Und wenn du irgendwann auch mal was nicht-triviales
> fertig haben willst, würde ich von sochen low-level APIs Abstand nehmen.
>
> Wenn du hingegen keine Programme für Endanwender schreiben willst und
> tatsächlich nur mit Low-Level-Grafik experimentieren willst, ist GDI
> unter Windows definitiv dein Ding, denn das ist eben die grundlegende
> API, auf der alle anderen aufsetzen.

Die neueren APIs setzen alle nicht mehr auf GDI(+), sondern nutzen 
DirectX, auch Qt (wenn auch über "Umwege" ANGLE -> DirectX).

[Peter II (Gast)]

Arc Net schrieb:
> Die neueren APIs setzen alle nicht mehr auf GDI(+), sondern nutzen
> DirectX, auch Qt (wenn auch über "Umwege" ANGLE -> DirectX).

GDI+ nutzt selber aber DirectX. GDI macht es nicht.

[Sam P. (Gast)]

Karl Heinz Buchegger schrieb:
> Und für die ersten Schritte in die Grafikwelt gilt genau das gleiche.
> <v<on welcher Programmiersprache aus die gemacht werden, ist ziemlich
> egal. Eine Linie auf dem Bildischirm ist eine Linie. Viele Linien sind
> ein Polygon. Und das kann man füllen. Die syntaktischen Feinheiten und
> wie man einen Brush oder Pen auswählt, um die Füllung bzw. Umrandung zu
> bestimmen ... das sind syntaktische Feinheiten der Sprache oder des
> Franeworks. Aber ein Rechteck sieht in im wesentlichen in der einen
> Sprache genauso aus wie in jeder anderen Sprache auch.

Da stimme ich dir vollkommen zu. Darum auch meine Anmerkungen zu GDI. 
Wenn man ein Gefühl dafür bekommen will, was dahinter steckt und wie 
komplex GUI eigentlich ist, finde ich GDI (oder meinetwegen DirectX) 
schon echt gut. Das ist wenigstens die offizielle Basis unter Windows, 
und es schadet niemandem, sich mal mit den wahren Grundlagen befasst zu 
haben.


> Das, wo einem ein Framework tatsächlich enorm unterstützen kann, dass
> ist die Anbindung ans Betriebssystem. Da gibt es viele verschiedene
> Abstraktionen. Aber die Prinzipien nach denen man komplexe Geometrien
> aus einfachen Teilen zusammensetzt, daran ändert sich nichts.

Genau, und da kommt es darauf an, was der TO will. Wenn es primär fertig 
werden soll, ist ein Framework der richtige Weg. Welches man da wählt, 
ist alles ein Stück weit subjektiv.

Ich schätze an Qt, dass ich mich nicht umgewöhnen muss, egal ob ich 
irgendwo mal ein kleines GUI-Tool baue oder embedded eine Touch-UI 
stricke, sei es unter Linux, MacOS oder ein billiger 
China-Industrial-Panel-PC mit WinCE, ich muss mich nicht umgewöhnen. 
Auch bei den großen Versionssprüngen kann man seine Gewohnheiten 
beibehalten und muss nicht alles gelernte vergessen. Dazu dann die 
Möglichkeit, Qt aus jeder relevanten Sprache heraus zu verwenden (nativ 
in C++, Python, oder meinetwegen auch C# und andere), das sind dann die 
Punkte, wo es den Unterschied macht.

wxWidgets mag ich überhaupt nicht, persönlicher Geschmack. Wenn es 
besonders kompakt werden soll, ist FLTK noch eine gute Alternative (300k 
für eine komplette Tabellenkalkulation sind da durchaus möglich, natives 
C++). Beim Komfort kommt aber nichts an Qt heran. Man kriegt einfach 
schnell viel fertig.


Arc Net schrieb:
> Silverlight -> XAML
> Silverlight for Windows Embedded -> XAML
> WPF -> XAML
> Windows Store Apps -> XAML und HTML
> Windows Phone -> XAML

Wie langlebig XAML sein wird, muss sich erstmal zeigen. Wie gesagt, 
genau diese Versprechungen der einzig wahren API hat MS schon öfter 
gebracht. Und gerade bei dieser Aufzählung drängt sich mir die Frage 
auf: Was kann XAML, was HTML5 nicht kann? (Das frage ich mich übrigens 
auch bei Qt's QML) Wenn man also eher in Richtung Mobil/Apps schielt, 
dann ist das eine ganz andere Kiste. Sollte man nicht da die Technik 
nehmen, die auf möglichst vielen Geräten läuft?

Aber wo ist XAML auf WinCE-5.0-Kisten, die man immer noch vorgesetzt 
bekommt ("Mach das mal da drauf, du hast gesagt Windows geht!")? Wo auf 
einem Cortex-M3? Das kann Qt alles.

Ach, aber was solls. Hauptsache anfangen. Ein Programm mit einem 
suboptimalen Framework erstellt zu haben ist besser als kein Programm 
fertig zu haben und immer noch nach dem perfekten Framework suchen.

[Karl H. (kbuchegg)]

Sam P. schrieb:

> Ach, aber was solls. Hauptsache anfangen. Ein Programm mit einem
> suboptimalen Framework erstellt zu haben ist besser als kein Programm
> fertig zu haben und immer noch nach dem perfekten Framework suchen.

Wo liegt die Liste auf, auf der ich unterschreiben kann?
Genau darum gehts! Wunderbar auf den Punkt gebracht.

[Arc N. (arc)]

Sam P. schrieb:
> Wie langlebig XAML sein wird, muss sich erstmal zeigen. Wie gesagt,
> genau diese Versprechungen der einzig wahren API hat MS schon öfter
> gebracht. Und gerade bei dieser Aufzählung drängt sich mir die Frage
> auf: Was kann XAML, was HTML5 nicht kann? (Das frage ich mich übrigens
> auch bei Qt's QML)

Android ebenso (auch XML). Das wird insgesamt noch eine spannende 
Entwicklung werden: Android, iOS, Windows.
Damit das ganze auch richtig OT wird:
Angefangen hat damit Palm: WebOS-Apps waren/sind HTML + JavaScript.
Und wenn JavaScript problemlos durch was anderes ersetzt werden könnte, 
hätte ich auch nichts gegen HTML5.

> Wenn man also eher in Richtung Mobil/Apps schielt,
> dann ist das eine ganz andere Kiste. Sollte man nicht da die Technik
> nehmen, die auf möglichst vielen Geräten läuft?

Also doch HTML5 + JavaScript

> Aber wo ist XAML auf WinCE-5.0-Kisten, die man immer noch vorgesetzt
> bekommt ("Mach das mal da drauf, du hast gesagt Windows geht!")?

5.0 noch nicht, erst ab 6 ;-)

> Wo auf einem Cortex-M3? Das kann Qt alles.

http://www.netmf.com/net-micro-framework-version-40-sdk-overview.aspx

> Ach, aber was solls. Hauptsache anfangen. Ein Programm mit einem
> suboptimalen Framework erstellt zu haben ist besser als kein Programm
> fertig zu haben und immer noch nach dem perfekten Framework suchen.

Full ack.

[Mark B. (markbrandis)]

Karl Heinz Buchegger schrieb:
> for( y = 0; y < 8; ++y )
> {
>   for( x = 0; x < 8; ++x )
>   {
>     if( x%2 == y%2 )
>       e.graphics.FillRectangle( whiteBrush, x*50, y*50, 50, 50 );
>     else
>       e.graphics.FillRectangle( blackBrush, x*50, y*50, 50, 50 );
>   }
> }

Ben _ schrieb:
> Das sieht auf jeden Fall leicht verständlich aus. Wie PHP.
> So jetzt ganz blöde Frage: Welcher Sprache entspricht das??

Ich verrate Dir jetzt mal ein Geheimnis:

C, C++, Java und C# haben vom Grundsatz her nahezu die gleiche Syntax! 
ALLE!

Das obige Beispiel sieht in Java auch nicht wirklich anders aus als in 
C# oder C++.

Jahaa, da staunst du was? ;-)