Einsteiger Fragen

  • Die Gefahr ist halt das Vergessen der Klammern, wenn man den Zweig erweitert.


    @amin: ich glaub in python wird der block ohne klammern über die einrückung abgegrenzt. findest du das besser? das wär dann ja einheitlich und gefahrlos erweiterbar wenn ich das problem recht verstehe.


    @michael: wow, vielen dank! jetzt funktioniert es tatsächlich :). glaub das war die letzte hürde, die für mein nächstes teilziel vor mir lag. ich hab da wohl einiges falsch gemacht bzw. noch nicht ganz richtig verstanden. aber ich hoffe mal die fragen klären sich bei meinem weiteren weg durch die dokumentation.


    ich würd mich ja gern selbst auch in diesem forum nützlich machen, aber wenn ich programmierratschläge geben würde, wär das wohl kontraproduktiv :D. falls jemand mal ne grafik frage hat, z.b. zu photoshop oder blender, vielleicht kann ich helfen!
  • Original von MartinH.
    Die Gefahr ist halt das Vergessen der Klammern, wenn man den Zweig erweitert.


    @amin: ich glaub in python wird der block ohne klammern über die einrückung abgegrenzt. findest du das besser? das wär dann ja einheitlich und gefahrlos erweiterbar wenn ich das problem recht verstehe.
    […]

    Ich weiß, dass manche Sprachen das so machen. Ich bin mir da unschlüssig. Immerhin hat es den Vorteil, dass man sich nicht so leicht über die Einrückung täuschen lässt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?
  • Original von MartinH.Falls jemand mal ne grafik frage hat, z.b. zu photoshop oder blender, vielleicht kann ich helfen!

    Grafik nicht zwingend. Mich interessiert eher, welche Möglichkeiten es gibt Photoshop mit anderen Dingen als Maus und Tastatur bedienen zu können. Nem Midi-Controller zum Beispiel. +lacht+

    Zum Thema 'Blöcke', 'C-Besonderheit' und 'Andere machens auch': Viele andere Programmiersprachen (PHP, Basic etc) orientieren sich an C. Deshalb haben sie wohl diesen Blödsinn übernommen.
    Ich mag Blöcke.

    Die erzwungene Einrückung bei Python ist meiner Meinung nach ausgesprochen hilfreich, da man immer übersichtliche weil schick formatierte Quelltexte hat.

    Zum Thema 'Autopairs/Englische Tastatur': Mittlerweile kann Xcode tatsächlich automatisch die zugehörige Klammer setzen, unabhängig von der gewählten Landeseinstellung.
    Das war ne Umgewöhnung... :D
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • zu photoshop. ich muss dazu erstmal sagen, dass ich eigentlich aus der windows ecke komm und sich daher alles was ich über alternative eingabewerkzeuge weiß auf winXP bezieht (ich hoffe ihr redet trotzdem noch mit mir :D ). aber viel ließe sich sicher mit ähnlichen tools unter OSX realisieren.
    erstmal gibts joytokey, ein kleines programm mit dem man jedes gerät das die standard-schnittstelle für joysticks und gamepads nutzt auf tastaturbefehle umleiten kann. so das man z.b. sowas benutzen kann um damit umständliche hotkey kombinationen auf einzelne tasten zu legen:
    [Blockierte Grafik: http://www.golem.de/0309/27513-nostromo.jpg]
    dann gibt es von logitech einen controller namens "nulooq", aber soweit ich das mitbekommen habe wird der nicht mehr hergestellt und die treiber nicht mehr weiterentwickelt. ich hatte das ding mal, aber der treiber war schrott und brachte hin und wieder mein photoshop zum absturz. dafür gibts nativ osx treiber, aber weis der geier ob die noch mit aktuellen versionen von osx laufen.
    media.createdigitalmedia.net/c…/2006/July2006/nulooq.jpg
    midi controller gehen garantiert auch, aber mit 3 einschränkungen. 1. du brauchst etwas das dir die midi signale auf tastaturinputs umleitet, 2. du brauchst genügend freie shortcuts in photoshop die du mit neuen funktionen sinnvoll belegen könntest, es ist krass wie "voll" die tastatur da schon ist, und man will ja eigentlich mehr funktionen durch so einen controller, nicht nur die von der tastatur auf was anderes legen (also ich würd das wollen).
    nativ unterstützt photoshop sowas leider überhaupt nicht. und ich glaube adobe ist nicht sehr kooperativ was das freilegen von schnittstellen angeht.
    3. mit reglern, fadern, drucksensitiven pedalen und dergleichen wirst du nicht viel anfangen können, photoshop unterstützt soweit mir bekannt nur grafiktablets als für drucksensitive eingaben. wenn du ein grafiktablet hast (ich empfehle unbedingt und ausnahmslos die marke wacom), dann hast du ja schon etwas mit dem du drucksensitive eingaben machst. diese dann z.b. mit nem fußpedal zu "überschreiben" wär vielleicht möglich wenn man ein programm schreibt, das sich in den wacom treiber einhakt und die an photoshop gesendeten werte manipuliert. aber da seh ich den sinn nicht. es hat mal jemand nen hack für den windows treiber von wacom programmiert und da so einige bugs rausgepatched. theoretisch geht das sicher auch am mac, aber ich seh wie gesagt nur mäßig viel nutzen.
    da du jetzt nach MAUS und tastatur gefragt hast, möchte ich noch einmal unterstreichen, dass ein wacom grafiktablet wohl eins der sinnvollsten eingabewerkzeuge zur bedienung von photoshop ist. ich habe ein wacom intuos 3 din a4, mittlerweile gibt es die intuos 4 serie und auch einige günstigere serien mit namen "bamboo". allerdings hab ich von den neuen noch nix getestet und kann da wenig zu sagen. mein intuos 3 leistet seit gut 5 jahren treue dienste und wird häufig benutzt. wenn das nicht für die firma spricht weiß ichs auch nicht.

    p.s.: fehlermeldung: "es sind zu viele bilder in der nachricht enthalten"... es waren doch nur 2?!
  • Original von MartinH.
    3. mit reglern, fadern, drucksensitiven pedalen und dergleichen wirst du nicht viel anfangen können, photoshop unterstützt soweit mir bekannt nur grafiktablets als für drucksensitive eingaben.!

    Ein Regler und Fader ist ja nicht zwingend drucksensitiv.

    Die Grundidee wäre, dass das Drehen am Regler oder Schieben am Fader die Position des Schiebereglers in einem Filter ändern soll.

    Nun ja, werd mich bei Gelegenheit intensiv mit dem Midi-Krams auseinandersetzen.
    Ich behaupte, dass muss gehen. +g+
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • @amin: :D

    @lucas: du kannst in photoshop java scripte starten, soweit ich weis plattformübergreifend mit der entsprechenden scripting API. so ein script kannst du über einen hotkey der an eine aktion gekoppelt ist aufrufen. dann kannst du schonmal theoretisch den umständlichen weg gehen midi zu tasteneingabe, tasteneingabe zu aktionsaufruf, aktionsaufruf zu scriptaufruf, script macht die reglerveränderung. das ganze funktioniert theoretisch, praktisch hast du dann aber so viel verzögerung drin, das du damit nicht flüssig regler steuern könntest. vielleicht würde es gehen, falls es eine schnittstelle für photoshop gibt um von anderen programmen aus direkt zuzugreifen. dann könntest du eine java applikation schreiben die selbst den midi kram handled und dann direkt in photoshop auf die richtigen werte geht. ich denk auch das es irgendwie gehen muss. würde mich nebenbei auch sehr interessieren, falls du einen weg findest.
    ich wollte z.b. immer schon einen externen controller haben, um die farbton/sättigung/helligkeits regler der aktuell gewählten farbe zu ändern.
  • Original von Amin Negm-Awad
    Klar reden wir noch mit dir. Es ist wie überall: Der neue in der Klasse bekommt erst einmal Keile. Wenn er dann beim Fußball ein Tor schießt, bekommt er was vom Butterbrötchen ab.

    Aber vom Bier gibts nix!!!
  • Liebe Alle,

    vielen Dank für eure Hilfe! Dank euch und mehreren Tagen des Studiums diverser Tutorials und Handbücher, lichtet sich der Nebel (zumindest teilweise) ^^ . Ganz ist mir der Mix aus C und Objective-C jedoch noch nicht in Fleisch und Blut übergegangen. Wieso beispielsweise C Strukturen alá CGRect weiterhin existieren und es kein Objective-C Pendant dazu gibt...

    Es wäre auch nett zu verstehen, warum mir der folgende und eigentlich recht simpel anmutende Sourcecode kein Rotes Quadrat der Seitenlänge 100 auf den Bildschirm zeichnet...

    Erneut wäre ich euch für eure Hilfe sehr dankbar!

    Vielen Dank und liebe Grüße
    Loo.

    P.S.: Butterbrote und Bier für alle :) !


    Quellcode

    1. #import "NoNibAppDelegate.h"
    2. @implementation NoNibAppDelegate
    3. - (void)applicationDidFinishLaunching:(UIApplication *)application {
    4. // Override point for customization after application launch
    5. printf("Wird ausgeführt.");
    6. UIWindow* window = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];
    7. CGRect viewRect = CGRectMake(0, 0, 100, 100);
    8. UIView* view = [[UIView alloc] initWithFrame:viewRect];
    9. [view setBackgroundColor:[UIColor redColor]];
    10. [window addSubview:view];
    11. [window makeKeyAndVisible];
    12. }
    13. - (void)dealloc {
    14. [super dealloc];
    15. }
    16. @end
    Alles anzeigen
  • @loonyfoobar:
    ich bin selbst noch ein anfänger und hab mit den "normalen" interface sachen noch nie was gemacht, beim hauptproblem kann ich dir also nicht helfen. aber warum benutzt du printf und nicht

    Quellcode

    1. NSLog(@"wird ausgeführt");

    ich glaub das wär "korrekter".
    zur frage warum es zu einigen c strukturen keine objekt entsprechungen gibt, ich glaube von der performance her sind die wenigstens teilweise nicht so effektiv wie die c strukturen. und ich persönlich benutz auch fast immer lieber skalare werte oder strukturen aus skalaren werten, als objekte. wenn du gern objekte für sowas nehmen willst, schreib dir doch selbst welche, falls es noch keine gibt :). dann kannst du die funktionen auch genau auf deine anforderungen anpassen.



    ich hab jetzt endlich gerafft wie das mit den enums funktioniert, find die sehr praktisch für das was ich machen will. komme im grunde ganz gut vorran, aber ich hab nochmal eine frage. und zwar gibt es in meinem programm ein dataObject, das methoden zum erzeugen von gameObjects bereitstellt und diese in einem NSMutableArray speichert. jetzt sollen aber die gameObjects wissen welches dataObject (gibt immer nur eine instanz davon im spiel) sie erzeugt hat, um selbst auch die methode spawnObject vom dataObject aufrufen zu können. eine property auf die instanzvariable "GameObject *gameObject;" hat nicht funktioniert, warum weiß ich nicht. ich hab das dann über eine id property gelöst:

    Quellcode

    1. @interface GameObject : NSObject
    2. {
    3. id dataParent;
    4. }
    5. @property (readwrite,retain) id dataParent;


    und später in der methode spawnObject aus dem gameData objekt weise ich das dann zu über

    Quellcode

    1. newOb.dataParent=self;


    und es funktioniert soweit ich das beurteilen kann. ich hab nur das gefühl, es sei eventuell nicht die eleganteste lösung gewesen und eventuel schlechter stil. ist es das?!
    ich habe wie gesagt weder unterschiedliche instanzen von diesem datenObject das alles regelt und speichert noch habe ich vor dieser property jemals irgendwas anderes zuzuweisen als genau dieses object. die property soll auch nicht angesprochen werden von außen, sie wird nur vom datenobjekt bei der erzeugung des spielobjektes gesetzt. könnte ich in dem fall dann auch eine (readonly) property verwenden?
    etwas ähnliches mach ich noch an anderer stelle, da übergeb ich über genau so eine id property die referenz zu der "scene" in der sich alles befindet, weil darüber die sprites in der cocos2d engine initialisiert werden und das dataObject die verbindung zurück zur scene braucht. ich verlass an der stelle bestimmt das MVC pattern, aber es erscheint mir gerade einfach der sinnvollste und einfachste weg, und falls ich das ganze mal portieren wollen sollte müsste ich da nur eine methode innerhalb des models anpassen, die sich mit dem zuweisen des sprites beschäftigt.