Nagyon fontos, hogy valamilyen single-platform nyelvet válassz, így kevesebbet kell majd kompatibilitási problémákon aggódnod (mondjuk egy OS/2 -> MacOSX migráció esetén;)
Egyértelműen C#, de a Delphis topikban lehet hogy nem ezt javasolnák az emberek. :) Fejlesztőkörnyezetnek Visual Studio .NET vagy Sharpdevelop. (Bővebb infó a Google-n.)
Most szeretnék valamilyen programozási nyelvet elkezdeni. Még csak tapogatózom, így szerretném, ha segtenétek.
Olyan nyelvet keresek, ami nem a legbonyolultabb nyelvezet, de lehet vele közepesen nehéz szinten programot írni, valamint egy távoli adatbáziskezelő szervert elérő programot készíteni (Pl.: MySQL). Egyenlőre ez a célom (persze jövőben más is) :)
Kiszemelt nyelvek:
C# Delphi or win32 Delphi + .NET
valamint ezek mellé fejlesztőkőrnyezetet keresek....
Szeretmém, ha a tapasztalataitokat megosztanátok..
Sziasztok! Egy olyan felataom van, hogy adatbázisból kell kiolvasni képet, és azt egy pictureBox-ban megjeleníteni. Sajnos egy helyen kiakad a progi futás időben, és nem jövök rá, hogy mitől. Nézzétek már meg, ha tudtok, mondjatok valami tippet:
byte[] content = (byte[])myOleDataReader["pic"]; MemoryStream stream = new MemoryStream(content, true); stream.Write(content, 0, content.Length); Bitmap foto = new Bitmap( stream ); pictureBox1.Image = new Bitmap( foto ); stream.Close();
Ennél a sornál száll el: Bitmap foto = new Bitmap( stream );
Van egy programom (forrás nincs) ami flash drivra dolgozna, admin jogosultságú felhasználó esetén tökéletesen működik megtalálja listázza azokat, de ha mezei felhasználóként futatom akkor sajna semmit nem talál.
Félnapi refklektorozás után megtaláltam WMI hívásokat használ (ManagementObject, Win32_DiskDrive) a flash driveok kereséséhez.
Kérdésem az lenne hogy hol és milyen jogosultságot kell beállítani hogy ne csak adminként tudjam használni, azaz működjenek a WMI hívások?
"Egyébként az IDE nem használatának az idôhöz nem sok köze van, ha IDE-vel gyorsabb lenne, nyilván azzal csinálnám, de nem gyorsabb."
Persze lehet, hogy ezen konkret esetben az IDE elonyei nem jelentkeznenek nyilvanvaloan, de teny, hogy a modern IDE-k rengeteg idot takaritanak meg a fejlesztes folyaman. Pl. par honapos melo eseten ez mar jelentkezik. Ennel nagyobb projektekben az IDE-k nem hasznalata pedig egyenesen emberi eroforras pocsekolasnak minosul (legalabbis az en szigoru nezeteim szerint). Ezt csak ugy altalanossagban irtam, nem rad vonatkoztatva.
Egyébként az IDE nem használatának az idôhöz nem sok köze van, ha IDE-vel gyorsabb lenne, nyilván azzal csinálnám, de nem gyorsabb.
A feladatot, jelentem, megoldottam, méghozzá mégis az osztályok becsomagolása nélkül: öröm volt nézni, ahogy az EXE mérete visszafogyott a régire: :-))) A megoldás:
foreach (ManagementObject drivemedia in new ManagementClass ("Win32_DiskDrivePhysicalMedia").GetInstances()) { ManagementObject drive = new ManagementObject (drivemedia["Dependent"].ToString()); ManagementObject media = new ManagementObject (drivemedia["Antecedent"].ToString()); ... drive["Model"] ...
Az egyik felét megoldottam: a gyári MgmtClassGen.exe helyett írtam magamnak egy másikat (az MSDN-ben van egy hivatkozás, hogy ô is csak a .NET Frameworköt használja, azt nekem is szabad). Így már nincsenek benne a felesleges Description-attribútumok, sokkal komfortosabb így az egész.
A Win32_DiskDrivePhysicalMediára ez még nem megoldás, úgyhogy próbálkozom tovább.
Általában igazad van, de specifikusan most ez mind nem érdekes. A tulajdonságok nevei be vannak drótozva a programba, és az elsô futtatás rögtön kideríti, ha bármelyiket véletlenül elgépeltem, nem fog elôfordulni, hogy használat közben egyszer csak elromlik valamelyik.
Másrészt, elsô nekifutásra amúgy sem ér a dolog semmit, mert így sem mûködik, a
DiskDrive drive = (DiskDrive) disk["Antecedent"]
futásidôben Invalid cast lesz.
Harmadrészt, belenéztem, elsôsorban attól lesz olyan sok a lefordított kód, hogy belemásol minden Description szemetet, ami csak ahhoz kell, hogy az IDE-ben rákereshess, hogy melyik mezô mit csinál; a lefordított programban igencsak feleslegesek ezek az összességében sok száz kilót kitevô stringek. Meg kellene találni, hogy lehetne magszabadulni tôlük (persze, valamivel automatizáltabban, mint a generált .cs-ekbôl kézzel kiirtva).
Negyedszer, akkor sem szeretem ma már az IDE-ket. Sok platformon és sok nyelven dolgozom egyszerre, a fene sem akar mindegyikhez sokszáz megás IDE-ket feltenni, mindegyik másként mûködik, néha akár össze is akadnak. Jobb nekem egy megszokott programozói szövegszerkesztô, szintaktikus kiszínezés abban is van, az automatikus befejezés meg a hátam közepére sem kell, gyorsan és jól gépelek, nekem ez a jó. A háttérben meg fut az MSDN (vagy más doksi), ha valaminek utána kell nézni. Én már megmaradok az ilyen régimódi megoldásoknál... :-))
Pedig eppenseggel jobban statikusan tipusossa teszi a WMI .NET-ben alapvetoen dinamikus tipusos hozzafereset, ami mindenkeppen hasznos. Raadasul a statikus lekepzes ebben az esetben eleg egyertelmu. Sajnos a kodgeneratorok altalaban viszonylag szukosen hasznalhatoak, igy hasznaljuk, amikor lehet.
A disk["Model"] es a disk.Model kozotti kulonbseg az eliras kiderulesenek idejeben van. Az elso esetben a hiba futasi idoben derul ki, az utobbiban forditasiban. Mindenkeppen nagyon ajanlott a hibalehetosegeket forditasi idben ellenorizhetove tenni. Az utobbi elonyei az intelligensebb IDE-k eseteben is jelentkezik, mivel ezek altalaban tipus informaciokbol nyerik a kontextus seged informaciokat, igy sokszor ki sem kell irni, hogy disk.Model, az ide befejezi neked.
Viszont a MgmtClassGen.exe-t ismerem, azt próbáltam is, csak ôszintén szólva, nem tesztett annyira, hogy minden egyes ilyen osztályhoz 50-100k-nyi ballasztot generál, így aztán el is feledkeztem róla. Ha nincs más megoldás...
Alapvetôen az a bajom, hogy míg egy szimpla osztálynál tudok így, egyszerûen haladni vele:
foreach (ManagementObject disk in new ManagementClass ("Win32_DiskDrive").GetInstances()) { ... disk["Model"] ... }
És ez nekem elég is, nincs igazán szükségem a MgmtClassGen generálta osztályra csak azért, hogy disk["Model"] helyett disk.Model-ként hivatkozhassam rá (és egyébként a háttérben ô sem csinál mást, mint meghívja disk["Model"]-nek, tehát gyorsabb sem lesz, csak kevesebbet kell gépelni, na bumm).
Csak az a bajom, hogy a Win32_DiskDrivePhysicalMedia további objektumokat ad vissza, és azokhoz nem tudok egy ugyanilyen ManagementObjectet csinálni magamnak, pedig ez lenne a legjobb megoldás.
Kösz, próbálkozom tovább; nincs VS-em, és amúgy nem is nagyon hiányzik (van C++-hoz, de ott sem használom az IDE-t, csak a parancssori változatot másoltam fel magamnak, és makefile-ból hívom meg, én jobban szeretem így).
WMI-vel kapcsolatos kérdés. A szokásos Win32_ osztályokat lekérdezni egyszerû dolog, de most nekem a Win32_DiskDrivePhysicalMedia kellene, amelyik két további osztály, a Win32_DiskDrive és a Win32_PhysicalMedia között teremt kapcsolatot:
foreach (ManagementObject disk in new ManagementClass ("Win32_DiskDrivePhysicalMedia").GetInstances()) { Win32_DiskDrive drive = disk["Dependent"]; Win32_PhysicalMedia media = disk["Antecedent"]; ... drive["Model"] ... }
A probléma az lenne, hogy hol van ez a két osztály (Win32_DiskDrive és Win32_PhysicalMedia) definiálva? Az MSDN szerint a Cimwin32.mof fájlban, de hogy segít ez rajtam?
