Egy kis segítség kellene, próbáltam utánanézni, de azt se tudom hogy keressem

formázva akarok kiírni, de úgy, hogy megadni hogy, honnan kezdje a kiírást, hány karakter szélesen, tehát egy táblázatos formát akarok kiírni, de
Console.WriteLine("{0} {1,20} {2,20} {3,20}", "Dátum", "Szolgáltatás neve", "Szolgáltatás hossza", "Szolgáltatás ára");
Console.BackgroundColor = ConsoleColor.Black;
for (int i = 0; i < fromDate.Length; i++)
{
Console.WriteLine("{0} {1,20} {2,20} {3,20}", fromDate[i], service[i], timeNeeded[i], price[i]);

ez egyáltalán nem akar jó lenne, és ha ki is hozom, hogy egy oszlopba kezdődjenek, akkor esetlegesen egy hosszú szó rögtön eltolja az egész sort

Xbox One: bandymnc

esetleg ha tabot használsz?
"{0}\t{1,20}\t{2,20}\t{3,20}"

végül is egynek így is jó, csak ha hosszabb lesz 1 szó mint a többi, akkor tolja a sort mint itt:

persze ezt is meg lehet oldani tabbal,csak gondoltam van rá jobb megoldás

Xbox One: bandymnc

https://github.com/Robert-McGinley/TableParser

Egynek jó lehet.

Ha van egy property nevem, akkor hogyan használhatom azt fel egy expressionben, az alábbi példában a Username helyett?

@helper CreateFormGroup(string labelName, string propName, object htmlAttr)
{
<div class="form-group">
<label for="Password" class="control-label col-md-3">@labelName</label>
<div class="col-md-9">
@Html.EditorFor(m => m.Username, htmlAttr)
@Html.ValidationMessageFor(m => m.Username)
</div>
</div>
}

Hú, te valamit nagyon fordítva akarsz csinálni.
Ez így alapjaiban nem jó, azt akartad kérdezni, hogy hogyan készíts saját custom HtmlHelpert nem pedig, hogy a saját próbálkozásodon mit tákolj. Vagy hogyan overrideold a meglévő EditorFor implementációt. Szerintem.
Egyébként meg a gugli segít, ha már tudod mit akarsz kérdezni (javasolt keresőszavak: extend, override, custom editor template)

[ Szerkesztve ]

Én kérek elnézést!

Sziasztok nagyon kezdő vagyok főleg c#-ban főleg az ilyen osztályok közötti mászkálásban az Githubon található repo-ból szeretnék tovább dolgozni konkrétan az elején elakadtam. [link]

Amit ő csinált az megy rendesen gond nélkül leforgott.

Az általa létrefohozott formon szeretnék a gombon egy onclick funkciót, amiben használnom kéne a TaskpaneIntegration-ben privátként definiált mSolidWorksApplication változót használni.

Probáltam szimplán publikussá tenni, de ez nem volt elegendő.

Remélem elegendő infót csatoltam a kérdéshez és azt is hogy tud valaki segíteni.

LEDE - R3G/DIR860l -> https://tinyurl.hu/Ntkb/

Sziasztok,

igazat megvallva nagyon alap szinten vagyok programozásban, és ezért szeretném a segítségeteket kérni. A szakdolgozatomhoz találtam egy programot, ami a webcam képét jeleníti meg, illetve annak a szűrőkkel ellátott fajtáit. Az egyik ilyen szűrővel ellátott pictureboxon szeretném alkalmazni a PixelCount vagy a PixelCountWithoutBlack parancssort, és az így kapott pixelek számát egy label-ben megjeleníteni. Addig tisztában vagyok a dologgal, hogy egy dupla for ciklusban kell a picturebox szélességét és magasságát megadni, de ezután nem tudom, hogy kéne folytatnom. Remélem sikerült érthetően leírnom, és valaki tud rá jó megoldást ajánlani.

Segítségeteket előre is köszönöm!

Sziasztok!

Teljesen tudatlan vagyok a témában, de van egy kis program, amire nagy szükségem lenne, viszont nem tudom paraméterezni. Itt minden infó megvan róla, de nekem sehogy nem megy a konfigurálás, nem is értem, hogy mit tudnék átírni, hogy működjön. (fájlnevet már próbáltam nem segít... )
Szóval erről van szó: https://github.com/Kappa71/PWM

A lényeg, hogy alapból 600Hz-es frekvenciát állít be, míg nekem legalább 1000, de inkább 2000Hz kellene, vagy akár több. Akármit csinálok, nem tudom változtatni az értéket, pedig a readme-ben azt írja, hogy lehet.

Valaki tud valami megfejtést? Gondolom az elérhető programkódok alapján egy másik verziót készíteni nem olyan nagy dolog, de életemben nem foglalkoztam még ilyennel.

Kösz, és bocs, ha nagyon világtalan vagyok...

(ui.: magát a nagy frekvenciás vezérlést teszteltem már, az rendben van, viszont az csak dedikált GPU-val megy, ez meg Intelhez kellene)

Akármit csinálok

Pontosan mit csináltál? Mert ennek egész egyszerűen paraméterben kell megmondani a frekvenciát, még példa is van hozzá.

Jester

Bocs, a lényeg kimaradt, ha futtatom a konzolt, akkor egy pillanatra megnyílik a parancssor, de kb. azonnal be is zárja, még ctrl+s-el se nagyon tudtam megállítani. Azt ki tudtam hámozni, hogy kiírja, 600hz-en fut, és tényleg, onnantól kezdve csökken a vibrálás. Viszont hol adom meg a paramétert?

Én csak az exe-ket szedtem le. Kellene valamelyik .cs fájl, amit átírok?

Nem kell semmit átírni az exe-nek kell paraméterben megadni. IntelPWMCA_Console.exe 2000

Nyiss egy cmd ablakot magad és abban futtasd, akkor nem tűnik el.

[ Szerkesztve ]

Jester

Bemész a mappába ahol az exe található, shift+jobb klikk parancsablak nyitása itt (újabban powershell ablak nyitása itt), begépeled IntelPWMCA_Console.exe 2000, enter, örül

[ Szerkesztve ]

Soha nem paramétereztem exe-t, de most futtatásba beírtam az elérési utat és a paramétereket, működik! Kösz, Viszont a parancssor így nyitva marad, illetve azt szeretném elérni, hogy az indítópultba téve (win7), paraméterezve induljon el automatikusan, és csukja is be maga után a parancssort.

Exe-n jobb klikk, a "Cél" opcióban az exe elérési útja mögé írd be hogy 2000, aztán az exe parancsikonját küld be az indítópultba.

Szuper, mindenkinek nagyon köszönöm, sikerült kigyomlálni a 220Hz-es vibrálást a laptopomról.
Azt el tudom érni, hogy a parancssor magától bezárjon? Mondjuk ez már nem olyan nagy gond, de jól jönne.

Srácok, iránymutatást kérnék. Előrebocsátom, hogy PHP-ban jobban otthon vagyok, mint C#-ban, de ez sem teljesen idegen számomra.
Megörököltem a cégnél egy "Terike néni feladatát megkönnyítendő" windows forms alkalmazást. Csak desktop, csak Windows 7/10, eddig egyszerű. A program a cégnél más, különböző alkalmazások, ill. a webes rendszer által generált egységes XML-ből szedi ki a szükséges adatokat és teszi be az adott gépen futó adatbázisba (kvázi innen-onnan gyűjtött XML-ből helyi adatot konvertál).
A program kezelője a formon csak simán bekkattintotta a fájlokat, mehet gomb, kilép gomb. Ez már működik.
Felmerült, hogy task schedulerből kéne időzítetten is működtetni, tehát parancssorral indíthatóvá kéne tennem.

Valahogy így:
programom.exe bemeneti_file.xml mit_csinaljon_vele

Ami eddig megvan:
Form1_Load(object sender, EventArgs e)
{
..
string[] args = Environment.GetCommandLineArgs();
if (args.Length > 1) FromConsole(args);
...
}

Az args tömb első (0.) eleme az exe útvonala, ezért ha a mérete nagyobb 1-nél, akkor parancssorból kaptuk az adatokat, meghívjuk a FromConsole() metódust. A második paraméter a fájl lesz, eddig pipa, az eddigi tallózás helyett (létezési ellenőrzéssel) már meg is van a fájlunk. A második az a művelet, amit szeretnénk tenni vele. Itt kéne optimális esetben az adott gomb eseményét meghívni, ennek végén pedig egy Close() lesz.

- tudok-e úgy hívni egy gomb eseményt, hogy a nevét ismerem sztringként (parancssori paraméter)?
- tudom-e ellenőrizni, hogy a metódus létezik-e?
- mennyire jó ötlet rögtön így hívni egy eseményt? és ha nem stimmelnek a metódus paraméterei?
- ha valami beüt (nem valószínű, de esetleg hibaüzenet, felhasználói interakcióra várás), kilép-e a program simán egy Close() esetén?

Reflection-nel megoldható, (itt egy gyors példa), de jó ötlet ettől még nem lesz

Ettől féltem én is. Fog majd utálni az, aki utánam kapja meg ennek a továbbvitelét
Hogy lehetne ezt becsületesen, szépen áthidalni?
Csináljam meg szépen a parancssoros metódusokat, ugye?

Közben úgy tűnik, a legutolsóra találtam megoldást. Amúgy is van naplózás SQLite db-be, ami MessageBox.Show() stílusú üzenet, azokat kiszedem, és csak a naplóba megy (eddig egymás mellett volt mindkettő), így ha jól tippelek, a FromConsole() végén lévő Close() már nem lehet akadály, ha a hibák jól le vannak kezelve...

[ Szerkesztve ]

Pl. a gombok eseményét tedd ki egy osztályba / metódusba valahova és azt hívd a gomb clickre is és paraméterből is.

Kilépéshez exception kezelés, log írás és ha ez a cél akkor kilépés (Environment.Exit).

[ Szerkesztve ]

Már elkezdtem, csak eleinte ódzkodtam tőle, mert rengeteg esemény van (ahogy írtam, én is örököltem), de hosszútávon ez tűnik a logikus lépésnek. Ha minden igaz, exception kezelés rendben van, még a loggolást kell jobban átszerveznem. Ráadásul úgy tűnik, csak a legfontosabb funkciókat kell tudnia parancssorból indítva tudnia, így könnyebb lesz kicsit.
Bár nagyobb meló, de úgy tervezem, hogy a metódusokat kiteszem egy osztályba, ahogy javasoltad, a Form-éban csak a gombok kezelői, meg a parancssor lekezelése lesz.
Remélem, a kitartásom a közepén is megmarad

Azt hogy tudnám megoldani, hogy egy nagyobb XML foreach-es végigjárása alatt is frissüljön a GUI és ne fagyjon be, míg végig nem szalad az állományon?

Durva példa (nem copy, itthonról, fejből):
foreach (XmlNode node in Blabla)
{
foreach (XmlNode child in node.ChildNodes)
{
}
}

Addig, míg esetleg egy 100-150 MB-os fájlon a foreach végig nem megy, addig semmi visszajelzés nincs, hogy hol tart, mit csinál éppen.

[ Szerkesztve ]

Külön szálon kell végezni a műveletet. Ha formos környezet van, akkor használhatod a BackgroundWorker komponenst is.

Srácok, egész jól kiszerveztem a metódusokat egy class-be, sőt, egy helper osztályt is készítettem. Viszont eléggé bőbeszédű lett a kódom.

Így néz ki a kiszervezésem:
namespace XmlProcess
{
class Base
{

}

class Helper
{
public static void EzEgyMetodus()
{

}
}
}

Viszont a Winformsból így tudom használni:
XmlProcess.Helper.EzEgyMetodus();

Lehet rajta egyszerűsíteni, hogy ne kelljen a namespace.class.metódus() szentháromságon mindig végigmenni, vagy fogadjam el, hogy a strukturálásnak, átláthatóságnak és a kiszervezésnek ennyi hátránya van?

[ Szerkesztve ]

Gondolom a Helper class is static, így mehet felülre a using static XmlProcess.Helper;

Utána tudod hívni bármelyik metódusban a kívánt függvényt:

pl.

void main()
{
EzEgyMetodus();
}

[ Szerkesztve ]

Na ez magamtól nem jutott volna az eszembe.
A using deklarációval próbálkoztam, de nem fogadta el, most már tudom, hogy mert a class nem volt static.
Azzá tettem, így már működik.

Szerk:
Elkiabáltam (nem fordítottam le), mégse működik.

using static XmlProcess.Helper;
"Identifier expected; 'static' is a keyword"

using XmlProcess.Helper;
"A using namespace directive can only be applied to namespaces; 'XmlProcess.Helper' is a type not a namespace"

Jó ez a C#, de rengeteget kell még tanulnom. A programozás, mint olyan nem idegen nekem, pláne 7 év (nem folyamatos) PHP után.

[ Szerkesztve ]

Ha tényleg "helper" az osztály, akkor miért nem static? Miért kell példányosítani?

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Már static. De így se jó

a using static c#6 feature, ha régebbi a projekted akkor nem fog menni, ez esetben marad simán
using XmlProcess

Ha jól emlékszem sok helper-ed van, amibe inkább van vastagon kód.
Miért nem hasznalsz valami DI-t rá? Azt akár staticba is bind-olhatod, ha akarod, de szerintem használni is egyszerűbb.

Autofac, ninject

[ Szerkesztve ]

“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”

Megint én.
Metódusnak paraméterként hogy tudnék átadni egy nem példányosított, adatokkal feltöltött dictionaryt?

Valami ilyesmi kéne:
CsinaljValamit(Dictionary<string,string>() { {"kulcs","ertek}, {"kulcs","ertek"} })

A metódus egyetlen paramétere egy kulcs-érték párokat tartalmazó <string,string> Dictionary.

Köszönöm!

#7883 adam014:
Hűha, ez nagyon gyors volt, köszönöm!
Akkor jó felé kapisgáltam, "csak" a new maradt le. Tekintve az eddigi C# előéletemet, lehetek egy picikét büszke magamra? Rád pedig, persze nagyon

[ Szerkesztve ]

CsinaljValamit(new Dictionary<string,string>() { {"kulcs","ertek"}, {"kulcs","ertek"} })

[ Szerkesztve ]

Sziasztok, csináltam egy példa kódot List<List<Color>> struktúra létrehozására. Tudom, hogy a listakreálás lassú, stb, de szükségem van a felxibilitására.

Készítettem egy benchmarkot úgy hogy párhuzamosság nélkül kreálok egy 4000 elemű List<> szerkezetet amit List<Color> elemeket tartalmaz (4000 elemű lista üres List<Color> elemekkel). Majd ugyanezt a listát megkreálom 250 elemű szublisták konkatenálásával, melyeket külön taskonként asszinkron módon hozok létre.

A kód változtatás és többletmunka nélkül fordul Visual Studióban

azt látom, hogy a párhuzamosítással nem tudok érdemi sebességelőnyt elérni. Én csinálok valamit nagyon rosszul, vagy a .NET olyan ravasz, hogy a List<List<>> kreálását már magától párhuzamosan végzi???

Előre is köszi !

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Drawing;
using System.Diagnostics;

namespace ConsoleApp30
{
class Program
{
private const int width = 4000;
private const int height = 3000;

//Ez lesz a delegate függvény a Taskok megkreálásához
static public List<List<Color>> createSublist (int n, int height)
{
List<List<Color>> result = new List<List<Color>>(n);

for (int i = 0; i< n; ++i)
{
result.Add(new List<Color>(height));
}
return result;
}


static void Main(string[] args)
{

Stopwatch stopwatch = new Stopwatch();
Stopwatch stopwatch1 = new Stopwatch();
List<List<Color>> pixelList = new List<List<Color>>(width);

//Listakreálás párhuzamosítás nélkül
stopwatch.Start();
for (int i = 0; i < width; ++i)
{
pixelList.Add(new List<Color>(height));
}
stopwatch.Stop();
Console.WriteLine("Sequential :" + stopwatch.ElapsedMilliseconds);
stopwatch.Reset();

int numOfCores = Environment.ProcessorCount;
int numOfTasks = numOfCores * 4;

Task<List<List<Color>>>[] tasks = new Task<List<List<Color>>>[numOfTasks];

long[] threadCreations = new long[numOfTasks];
stopwatch.Start();
for (int i= 0; i< numOfTasks; ++i)
{
stopwatch1.Start();
tasks[i] = new Task<List<List<Color>>> (() => createSublist(width / numOfTasks, height));
stopwatch1.Stop();
threadCreations[i] = stopwatch1.ElapsedMilliseconds;
stopwatch1.Reset();

}
for (int i=0; i< numOfTasks; ++i)
{
tasks[i].Start();
}

for (int i = 0; i < numOfTasks; ++i)
{
Console.WriteLine("Task nr {0} state: {1}", i, tasks[i].Status.ToString());
}

Task.WaitAll(tasks);
stopwatch.Stop();

Console.WriteLine("Creating {0} sublists in parallel took: {1} ms", numOfTasks, stopwatch.ElapsedMilliseconds);
stopwatch.Reset();

for (int i = 0; i < numOfTasks; ++i) {
Console.WriteLine("Creating task nr {0} took: {1} ms", numOfTasks, threadCreations[i]);
}


stopwatch.Start();
IEnumerable<List<Color>> result = tasks[0].Result.AsEnumerable();
for (int i = 1; i < numOfTasks; ++i)
{
result = result.Concat(tasks[i].Result);
}

var cList = result.ToList();
stopwatch.Stop();

Console.WriteLine("Concat of {0} Lists took :{1} ms", numOfTasks, stopwatch.ElapsedMilliseconds);
stopwatch.Reset();

}
}
}

[ Szerkesztve ]

Sequential :46211
Creating 64 sublists in parallel took: 796 ms
Concat of 64 Lists took :3 ms

Monduk ez mono-val linuxon és elég gyanús a sebességkülönbség, lehet, hogy nem egy futásba kellene a kettőt tesztelni.
Ahha, nem tudom mit mókol (valami inicializáció vagy ilyesmi) de ha a szekvenciálisat kiveszem akkor már 11679 ms a párhuzamos. Azt már elhiszem, hogy négyszer gyorsabb.

[ Szerkesztve ]

Jester

Köszi hogy kipróbáltad!

ez ugye a párhuzamos eredménye:

var cList = result.ToList();

Tehát a cList változó.

Elképzelhető, hogy a Mono fordítója észreveszi, hogy a cList semmire sincsen használva, az előtte lévő Concat függvénynek meg ugye a taskoknak sincsenek mellékhatásai, ezért a cList kiszámításához vezető utat kioptimalizálja (= ki sem számítja)?

SZERK:
Nálad valahogy iszonyat jól gyorsul: 796ms x 64 = 51sec az alig több mint a 46sec.

De ennyit nem szabadna sehogy sem gyorsulnia, én ugye a Taskok számát a logikai procimagok száma x 4-re vettem. A max gyorsulás amit várnék az a logikai procimagok arányában lenne (nálam 4, nálad 16(????))

[ Szerkesztve ]

Hát itt össze-vissza van minden, még futások között is. Ahogy elnézem, a garbage collection miatt van ekkora szórás. Teszek bele egy pár GC.Collect()-et

Jester

Aha, kétféle GC közül lehet választani, a másik az jobb

Sequential :48ms, count = 3840
Creating 64 sublists in parallel took: 55 ms
Concat of 64 Lists took :2 ms, count: 3840

Ha adok neki többet:

Sequential :232ms, count = 19200
Creating 64 sublists in parallel took: 239 ms
Concat of 64 Lists took :3 ms, count: 19200

Ez meg nem gyorsul egyáltalán, a lista allokáció az lehet, hogy lockol a háttérben.

Jester

JIT-et beleszámoltad? (első futás sokkal lassabb) Ez nem pontos így, Benchmark.NET-el kéne benchmarkolni nem stopwatchokkal.

JIT-et beleszámoltad? (első futás sokkal lassabb) Ez nem pontos így, Benchmark.NET-el kéne benchmarkolni nem stopwatchokkal.

Addig még nem jutottam, de az eredmények futtatások között nagyon konzisztensek, pár százalék eltérés van a mérések között...

Mit is szeretnél elérni? Mert szerintem ennek itt semmi értelme.

Color adatokat szeretnék egy List<List<Color>> struktúrában tárolni. BMP képnek az adatai lesznek benne, tehát akár 10-20 millió képpont (4 byte) is tárolódhat itt.

Azért kell a List<>, mert szinte véletlenszerűen egy sornyi vagy oszlopnyi pixel (de nem ugyanabból a sorból vagy oszlopból) kieshet. ekkor pedig szeretném a kiesett pixeleket kiszedni a pixellistából, hogy ne maradjanak lyukak, minden pixelnek legyen érvényes szomszédja. Tehát úgy gondolom, hogy a statikus tömb nekem nem jó a rengeteg átméretezés miatt. (bár az egy opció, hogy statikus tömb memóriaterületét oszloponként a listába másolom, de itt nem tartok)

Kb 300ms kell, mire egy List<> listát lefoglalok, amely 4000 darab üres List<Color> -ból áll. Szeretném ezt lerövidíteni, de a művelet végén mindenképpen dinamikus listát szeretnék látni.

[ Szerkesztve ]

Nem tudom hogy akarod utána használni, de egy sor/oszlop index ami megmondja hogy az i. sor/oszlop az fizikailag melyik sor/oszlop az viszonylag egyszerű törlést tesz lehetővé.

Jester

Számon tartok egy gradiens táblázatot is, amely az egyes képpontok szomszédainak eltérőségét adja meg.

valueMap[x][y] = sqrtLookup[
sqr[Math.Abs((pixelList[modKadder(x, 1,width)][y].R - pixelList[modKadder(x, -1, width)][y].R))]
+ sqr[Math.Abs((pixelList[modKadder(x, 1, width)][y].G - pixelList[modKadder(x, -1, width)][y].G))]
+ sqr[Math.Abs((pixelList[modKadder(x, 1, width)][y].B - pixelList[modKadder(x, -1, width)][y].B))]
//+ sqr[Math.Abs((pixelList[modKadder(x,1,width)][y].A - pixelList[modKadder(x,-1,width)][y].A))]


+ sqr[Math.Abs((pixelList[x][modKadder(y, 1, height)].R - pixelList[x][modKadder(y, -1, height)].R))]
+ sqr[Math.Abs((pixelList[x][modKadder(y, 1, height)].G - pixelList[x][modKadder(y, -1, height)].G))]
+ sqr[Math.Abs((pixelList[x][modKadder(y, 1, height)].B - pixelList[x][modKadder(y, -1, height)].B))]
//+ sqr[Math.Abs((pixelList[x][modKadder(y, 1, height)].A - pixelList[x][modKadder(y, -1, height)].A))]
];

minden Pixelpozícióra ki van számolva a gradiensfüggvény arra a pontra. Amikor egy képpont kiesik, akkor a szomszédainak (akik esetleg bentmaradnak) megváltoznak a szomszédai, tehát a gradienstáblázatot is updatelni kell azokban a pixelpozíciókban, ahol változás történt.

egy sor vagy oszlopnyi pixel fizikai (vagy logikai) törlése nagyságrendileg 4000 pixel törlését és 8000 pixelnyi gradiens újraszámítást igényel. Ha 1000 sort veszel ki, akkor mindezt 1000x. A gradiens újraszámítás pedig igényi, hogy gyorsan el tudd dönteni, hogy egy pixelnek kik a szomszédai. Nem rakhatok bonyolult logikát a ki-kinek a szomszédja meghatározásába.

[ Szerkesztve ]

az int sqrtLookup[] és az int sqr[] keresőtáblák, az első a gyökvonáshoz a második a négyzetreemeléshez (mondjuk ennek nem sok haszna van)

pixelList[x][modKadder(y, 1, height)]

Ez a kódrészlet fogja és kikeresi a pixellistából az [x][y+1] pozícióhoz tartozó pixel Color értékét. a modKadder egyszerűen annyit csinál, hogy az utolsó sorból (y = height-1) a nulladik sorba ugrat (y = 0) és fordítva. Ugyanezt az x tengely mentén az oszlopokra

"Lehet tényleg előrébb tartanék egy index-fordító táblázattal, kérdés, hogy a statikus tömbök rugalmatlansága mennyi plusz futásidőt eredményezne, elvinné-e a megtakarítást" - ha ez megnyugtat, akkor a List alatt is tömb van: [link]

Habár még mindig nem értem teljesen, hogy mit szeretnél, de bedobok pár kulcsszót, hátha ad ötletet: Thread-Safe Collections, TPL

mod: Szerintem egy 2 dimenziós tömbnek elégnek kellene lennie, az indexek alapján el tudod érni egy pixel összes "szomszédját", törlésnél meg lehet, hogy törlés (tömb átméretezés) helyett inkább egy speciális értéket (pl.: Color.Undefined - ezt ugye te definiálod) vagy null-t írnék be az adott helyre, és majd az enumeráláskor ellenőrizném utólag.

[ Szerkesztve ]

some men just wanna watch the world burn...

Ha képet rajzolsz, akkor miért nem a Drawing környékén jársz?

Ha az nem is jó neked, akkor pl. én nem használnék Color-t, mert az kicsit túl nagy, helyette egy int is megteszi vagy egy kisebb saját típus.