- Poco F6 5G - Turbó Rudi
- Bivalyerős lett a Poco F6 és F6 Pro
- Most a Galaxy S25 FE megjelenésére tippelnek
- Apple iPhone 15 - a bevált módszer
- Mobil flották
- Android szakmai topik
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Sony Xperia 1 VII - Látod-e, esteledik
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
Hirdetés
Új hozzászólás Aktív témák
-
Gregorius
őstag
Object.ReferenceEquals. Olyan nyelvi elem, ami garantáltan ezt csinálja csak VB.NET-ben van (Is operátor). A ==-t felül lehet definiálni (ugyanúgy, mint a sima Object.Equals-t), bár igen komoly szabályok vannak, hogy milyen körülmények között szabad és ha ezt nem tartjuk be, a fél framework elkezd rosszul működni az osztályunkon.
-
Gregorius
őstag
-
#1759
Gregorius
őstag
FehérHolló
#1758
Gregorius
őstag
válasz
FehérHolló
#1758
üzenetére
Ha jól látom, a BlockingCollection<T> az egy wrapper a ConcurrentQueue fölött, úgyhogy ha blokkoló viselkedésre van szükség, akkor ez a megoldás.
Továbbá ha nem szigorú követelmény, hogy a feladatokat érkezési sorrendben kell megoldani, akkor még ajánlanám a Task Parallel Library áttanulmányozását (TaskFactory.StartNew, stb). Ezzel pofonegyszerű több szálra szétpakolni a feldolgozást. -
#1752
Gregorius
őstag
FehérHolló
#1750
Gregorius
őstag
válasz
FehérHolló
#1750
üzenetére
Ha itt egy termelő-fogyasztó patternt kellene megoldani, ahhoz inkább a ConcurrentQueue<T>-t kellene használni. Ld. még System.Collections.Concurrent.
-
Gregorius
őstag
Itt valami többrendbeli probléma van, ugyanis nem a ClientInfo-t tárolod el a listába, hanem a callback channelt. Aztán kicsit odébb az ellenőrző loopban foreach (ClientInfo c in clients) ami gyönyörűen elszáll, ugyanis a listában lévő IChessClient elemeket nyilvánvalóan nem tudja ClientInfo-ra konvertálni. Ráadásul ez nem a main threaden jön, hanem egy háttérszálon, vagyis nem a kliens fog egy faultexceptiont látni belőle, hanem az IIS egyszerűen bedarálja és újraindítja a szolgáltatást.
Ezen túl még olyan hiba is van, hogy egy foreach-en belül módosítod a listát. Ettől az enumerator meghülyül és ugyanúgy exception lesz az eredmény, vagyis ha módosítani akarsz, akkor érdemes a foreach-ben egy ToList()-tel lemásolni a listát (using System.Linq).
Hogy ezek után működni fog-e azt egyelőre még nem látom, de ezeket mindenképpen meg kellene oldani.
Továbbá én a helyedben úgy csinálnám meg a service-t, hogy külön dll-ben van, mert aköré könnyebb szervezni az életed mind fejlesztés mind beüzemelés közben. Fejlesztéskor a VS beépített WcfSvcHost fogja neked futtatni a szolgáltatást minden külső függőség nélkül (egy követelmény van csak: Any CPU-ra kell fordítani), telepítéshez meg csak köré kell szervezned egy külön projektként a "bootstrappert" legyen az IIS, Windows Service vagy egy egyszerű konzolos alkalmazás ami folyamatosan írja a logot a képernyőre.
-
Gregorius
őstag
Egy gyors ötlet: dekoráld ki a ChessService-t ezzel:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
Ez megoldhatja az aszinkron hívás gondot.A másik pedig hogy statikus memberek helyett ugyanebbe az attribba az InstanceContextMode.Single-t kell még beírni, mert így egy darab ojjektum létesül a szolgáltatáshoz és ez szolgálja ki az összes klienst. Ha meg egy sincs, akkor nem foglalja semmi az erőforrásokat, mert a szerver is eldobja az objektumot. Ebben az esetben viszont Reentrant helyett a ConcurrencyMode.Multiple kell.
-
Gregorius
őstag
azt szeretném észlelni, amikor meghal egy kliens, hogy a másik játékos ne csak üljön és várjon a semmire, hanem tudjam jelezni neki
Ezzel a problémával az elmúlt fél évben én is szembesültem, sajnos erre nincs univerzális megoldás. Saját magadnak kell valamilyen keepalive megoldást implementálni. Akár úgy, hogy egy extra metódushívást beleiktatsz a kontraktba, ami periodikusan küld egy dummy üzenetet, akár úgy, hogy a csatornához fejlesztesz hozzá egy nagy adag saját extension-t. Bizonyos esetekben (pl. basicHttpBinding) a csatorna állapotmentes, tehát elvileg sem észlelhető, hogy a kliens jobb létre szenderült, mert a holtidőben semmilyen kapcsolat nincs.A kódhoz kellene még a konfig is. Nagyon sok mindent jobbá lehet tenni vagy katasztrofálisan el lehet rontani egy WCF szolgáltatás konfigurációjával.
Az mindenesetre már látszik, hogy ha void aszinkron hívásokat akarsz csinálni, akkor ajánlott az interfészen az OperationContract-ban megjelölni IsOneWay=true-ként és akkor nem kell külön szálat indítani minden ilyen híváshoz.
-
Gregorius
őstag
Azonban a struct legnagyobb "hátránya", vagyis az érték szerinti hivatkozás mellett max. 16 KB lehet az összes taggal együtt
Az egyetlen limit, amibe bele lehet ütközni, az a stack overflow valahol 1M környékén (64-bites app esetén kicsit kevesebb, mint 32-bites esetén). De ekkora struct létrehozásához már komolyan trükközni kell egymásba ágyazásokkal, ugyanis a fordító belső limitje miatt egyetlen structnak sem lehet 64k darabnál több fieldje. De ez a limit ugyanúgy vonatkozik classokra is.Megjegyzem az ajánlott struct méret a pár tíz bájt alatt van. Ennél nagyobb structnál már valószínűleg hatékonyabb classt használni. Egy szint fölött túl nagy overhead az egész struct tartalom másolgatása az átadásokkor.
nincs automatikus GC sem
Milyen GC-nek kellene lennie? A struct pont azért tud hatékonyabb lenni adott helyen a classoknál, mert önmagában semmilyen GC-ben nem vesz részt. Ha a stacken foglal helyet, akkor pontosan akkor szabadul fel a memóriaterülete, amikor kiesik a scope-ból. Ellentétben egy class változó által mutatott objektumot adott esetben csak később gyűjt be a GC. Ha boxolva vagy más objektum részeként van a struct a heapen, akkor persze ugyanúgy GC-ződik, mint egy sima class, utóbbi esetben pontosan akkor szabadul fel a területe, mint a tartalmazó objektumé.Ezek szerint nem érdemes C#-ban struct-ot használni?
Kisméretű adatcsomagok tologatására érdemes, ahol szemantikailag is indokolt a használata. Illetve mint az elhangzott P/Invoke esetén gyakran ezt követeli meg a hívás.Van még pár teljesítményprobléma, ami ellenjavallja a structok használatát, de ezek nem a struct jellegéből adódnak, hanem a JIT fordító retardáltságából és idővel valószínűleg megoldódnak.
Továbbá van egy érdekes használati mintája a structnak: hatékony wrappert lehet vele írni, amikor az öröklődés nem megoldható. Ilyenkor ugyanis a struct csak egyetlen objektumreferenciát tartalmaz és ez másolódik mindenhova. Ez gyakorlatilag azt jelenti, hogy a struct többé-kevésbé class szemantikával működik, annak megfelelő a memóriafoglalása is, csak egy rakás másik metódust rá lehet aggatni.
-
Gregorius
őstag
Pár félreértést eloszlatandó: a class is pontosan annyira threadsafe mint a struct: semennyire.
Az egyetlen különbség a kettő között - ami viszont nagyon komoly különbség - , hogy a classal ellentétben nem a referencia, hanem a tartalom utazik, ahogy passzolgatod. Vagyis a legalapvetőbb alkalmazások (pl. lokális változó) kivételével nem lehet az eredeti helyén egyenként módosítani a tagjait. Ha nem akarod elgáncsolni magad, akkor (kivételes esettől eltekintve) kizárólag immutable struktúrákat csinálsz, vagyis olyat, ami konstrukció után semmilyen formában sem változtatható. Így a fenti hiba koncepcionálisan kiküszöbölhető. -
Gregorius
őstag
válasz
ArchElf
#1493
üzenetére
Ez nem teljesen ugyanaz. A CLR támogatja az exception filtert, a VB.NET is, a C# nem. Lényeges különbség, hogy míg VB.NET-ben feltétel teljesülése esetén kapod el az exceptiont, C# esetén mindenképpen elkapod. Az exception filter logika a belső finally blokkok előtt fut le, a fenti C#-os megoldás feltétele utána.
-
#1429
Gregorius
őstag
FehérHolló
#1427
Gregorius
őstag
válasz
FehérHolló
#1427
üzenetére
Probléma, ha gyakran kell a GUI-ra írni?
Probléma. Egyrészt azért, mert a marshallozásnak költsége van, ami visszafogja a normál működést, másrészt mert az átlag emberi agy reakcióideje legjobb esetben is tizedmásodpercekben mérhető, vagyis teljesen felesleges ezredmásodpercenként frissíteni a GUI-t, mert mire a szerencsétlen felhasználó tudatáig eljut egy adat, addigra már a hatszázzal későbbi minta is rendelkezésre áll. Vagyis 599 mintát tök fölöslegesen írnál ki. -
Gregorius
őstag
válasz
REDeath
#1406
üzenetére
A klasszikus asp.net-ben a szerveroldali controloknak általában van egy viewstate-jük, ami utazik a kliens meg a szerver között (a sima postolt adatokon felül). Kellőképpen elvetemült esetben ez a viewstate kezelhetetlenül nagyra duzzad, ami az alkalmazás reakcióidején csúnyán meglátszik, és elég körülményes a méretére ráhatni fejlesztőként.
Asp.net MVC-t ez a probléma nem érinti. -
Gregorius
őstag
Ha már körbejárjuk a témát, kicsit még tovább is megyek. Ennél létezik egy általánosabb megoldás.
A Control.Invoke/BeginInvoke/stb. az WinForms környezetben használatos:
this.Invoke(new Action(...));
A háttérben pontosan ugyanezt csinálja a következő:
SynchronizationContext.Current.Send(
new SendOrPostCallback(...),
state);
továbbá betűről betűre ugyanez a kódsor működik WPF-fel, ASP.NET-tel és még COM+-os interoppal is, nem csak WinFormsszal.
Utóbbi esetben a BeginInvoke-nak megfelelő aszinkron hívás a Post.
-
Gregorius
őstag
Csak éppen semmit sem fog érni, mert a háttérben párhuzamosan kizárólag annyi történik, hogy a feladatot beütemezi az egyetlen egy főszálra. Vagyis a ThreadPool.Queue teljesen fölösleges. Ha mindenképpen aszinkron hívás kell, akkor Invoke helyett a BeginInvoke használatos.
-
Gregorius
őstag
válasz
#95561216
#1335
üzenetére
Nem tudom mennyivel lassabb egy c# kód, de gyanítom feláldoztak némi sebességet a gyors fejlesztés oltárán
Ez teljesen esetfüggő. Adott szituációban gyorsabb, adott szituációban lassabb. Ronggyá optimalizált intenzív számítási feladatnál valószínűleg lassabb.Amúgy azért c#-ra gondoltam, mert ez jobb befektetésnek tűnik a jövőbe, a managed c++-ra sok rosszat hallottam, valamint ehhez van könyvem
A managed C++-t részben pont arra találták ki, hogy ha az ember hibrid rendszert akar fejleszteni (sok a legacy c++ kód), akkor könnyebb dolga legyen. Tök új szűz projektnek érdemesebb C#-ban nekikezdeni. -
Gregorius
őstag
Túl sokat nem tudok segíteni, csak egy kicsit itt-ott.
A cold-start build valóban durván darálja a vinyót, a másodiknál viszont már sokminden a system cache-ből megy. A build enginek ráadásul ritkán használnak több magot - már ahol ez egyáltalán lehetséges - úgyhogy gyanítom, hogy itt a dolog inkább CPU limitessé válik.
C#, VB.NET illetve egyéb CIL-re forduló projekt majdnem biztosan felejtős. Sok olyan projekt még nem fordult meg a kezem alatt, ami egy perc alatt ne tudna könnyedén fordulni. Natív C++ alá viszont nagyságrendekkel tovább tartó buildeket is lehet találni. Érdemes valamelyik népszerűbb szabad szoftver csomagot választani, pl. OpenSSL, Apache httpd stb. Ezekben általában elég részletes dokumentáció is van, hogy mi kell a fordításhoz és hogyan kell lefordítani.
Egyébként szerintem leginkább a nagyon sok (>10000) nagyon kis fájl (1-100k) olvasása/írása vegyesen tesztesetre hasonlít a terhelés. Ha még erősen fragmentált is a vinyó - ami a fordítás közben keletkező sok kis fájllal könnyen kialakul, bár ez erősen fájlrendszer- és kihasználtságfüggő - akkor még jobban köhögnek a sok seekeléstől hagyományos HDD-k.
-
Gregorius
őstag
EF és L2S használata esetén a lekérdezések mindig az adatbázis szerveren hajtódnak végre
A lekérdezés ott hajtódik végre, ahol én mondom neki. Ugyanúgy, ahogy a TableAdapternél is megmondom, hogy milyen lekérdezést futtasson a szerveren, aztán a helyi adatokat tologatom. Aztán ha valaki beleesik abba a hibába, hogy a lekérdezést és nem a lekérdezés eredményét köti hozzá az objektumaihoz, magára vessen. Olyasfajta dedikált repository, mint a tableadaptehez a dataset, ami tárolja az eredményt valóban nincs EF és L2S alatt, helyette bármilyen beépített vagy saját gyártású listába beleküldheted az eredményt. -
Gregorius
őstag
A LINQ to SQL és az Entity Framework is ugyanúgy disconnected modellben dolgozik, mint a datasetes megközelítés. Maga az adatbázishoz kapcsolódás valóban kevésbé explicit, de architekturálisan ugyanaz a felállás: kliens kapcsolatot megnyitja, küldi a query szöveget, kapja az adatot, kapcsolatot lezárja.
A lényegi különbség ott van, hogy a kliensen hogy áll össze a command text illetve hogy a kapott adatból mi keletkezik.
Az EFv4 (végleges változat két hónap múlva) már kimondottan jól használható. -
Gregorius
őstag
Ez már végigmegy hiba nélkül:
Public Sub FindFiles(path As String, pattern As String, result As Collection(Of String))
Try
For Each s As String In Directory.GetDirectories(path, pattern)
FindFiles(s, pattern, result)
Next
For Each s As String In Directory.GetFiles(path, pattern)
result.Add(s)
Next
Catch ex As UnauthorizedException
End Try
End Sub
Dim res As New Collection(Of String)
FindFiles("C:\", "*.avi", res)
For Each s As String In res
listBox1.Items.Add(s)
Next2. Csak arra hívod meg a fentit, amelyikre kell.
-
-
Gregorius
őstag
Felteszem a VS 2008 SP1-et már telepítetted. Ha nem, pótold.
Az alapok:
1. Végy egy projektet
2. Adj hozzá egy új elemet: LINQ to SQL Classes. (Az ADO.NET Entity Data Model is hasonló célú, de a LINQ to SQL könnyebb és gyorsabb egyszerű adatbáziskezelésre, bár van benne néhány kellemetlenség, amit egyre fárasztóbb körbelőni, ahogy bonyolódik az alkalmazásod.) Ne felejts el nevet adni a fájlnak, legyen mondjuk EShop.dbml.
3. Kapsz egy üres felületet. Tanács szerint nyisd meg a Server Explorert, ha itt nem látod az adatbázisod, akkor fent ott van a "Connect to Database" gombóc, azzal hozzá kell adni. Majd ugyanebben az ablakban maradva kiválogatod, hogy az adatbázisokból mivel akarsz foglalkozni és egyszerűen ráhúzod az üres felületre. Mentés, bezárás.És ennyi, az infrastruktúra egyik fele készen van. A következő módon tudsz pl. egy tábla tartalmából listát csinálni:
List<Customers> customers;
using( var db = new EShopDataClasses() )
{
customers = db.Customers.ToList();
}A WPF oldal egy kicsit gáz, ugyanis habár a WPF-nek ezerszer jobb (lesz) az adatkötése (mihelyst rendes designer támogatás is lesz hozzá), utolsó értesüléseim szerint a WPF még nem rendelkezik olyan szofisztikált griddel, mint a WinForms. (A CodePlexen már van valami előzetes változat, amibe csak beledobod az adatot és mindent elintéz, de még nem az igazi) Úgyhogy inkább dolgozzunk azzal, amink van és csináljunk egy egyszerű megjelenített listát, amiben még csak lépkedni sem lehet kurzorral.
Ha WPF appot hoztál létre, akkor elvileg már van egy Window1.xaml-ed, használjuk ezt. Fejléc is kell, úgyhogy egy StackPanelben egymás alá rakjuk a fejlécet és egy ItemsControlt, ami a lista elemeit jeleníti meg. (Haladóknak van HeaderedItemsControl, de ott stílusokkal is kell vacakolni.) Kissé fapados és kézihajtányos, de erre a célra most jó lesz.
Lévén szeretnénk ha a fejléc és a tartalom nem csúszna el egymástól, mindkét helyen egy gridet fogunk használni közös méretezéssel. Az egyszerűség kedvéért most csak két oszlopot csinálok meg. A fejléc grid így néz ki:<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="100" />
<ColumnDefinition />
</Grid.ColumnDefinitions>
<TextBlock Grid.Column="0" Text="Customer ID" />
<TextBlock Grid.Column="1" Text="Company name" />
</Grid>A tartalomsablon szinte azonos vele:
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="100" />
<ColumnDefinition />
</Grid.ColumnDefinitions>
<TextBlock Grid.Column="0" Text="{Binding CustomerID}" />
<TextBlock Grid.Column="1" Text="{Binding CompanyName}" />
</Grid>Ahol a Binding mondja meg, hogy oda majd a CustomerID illetve a CompanyName mező kerül. A fix méretezés kicsit gáz, rá lehet venni a grideket, hogy együtt méreteződjenek, de az már a haladó kurzus része.
Az egész összeépítve:<StackPanel>
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="100" />
<ColumnDefinition />
</Grid.ColumnDefinitions>
<TextBlock Grid.Column="0" Text="Customer ID" />
<TextBlock Grid.Column="1" Text="Company name" />
</Grid>
<ItemsControl Name="DataList" ItemsSource="{Binding}">
<ItemsControl.ItemTemplate>
<DataTemplate>
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="100"/>
<ColumnDefinition />
</Grid.ColumnDefinitions>
<TextBlock Grid.Column="0" Text="{Binding CustomerID}" />
<TextBlock Grid.Column="1" Text="{Binding CompanyName}" />
</Grid>
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>
</StackPanel>Itt két dolog van, amit még nem érintettem: az ItemsControlon a Name teszi lehetővé, hogy kódból hivatkozzunk rá, továbbá még meg kell adni az ItemsControlnak, hogy az elemeit honnan vegye. Ez legyen egyszerűen {Binding}, akkor a saját DataContext-jéből veszi az elemeket, azt pedig kódból máris beállítjuk a főablak Loaded eseménykezelőjében, itt ér össze a WPF és a fentebb lekért adat:
private void Window_Loaded(object sender, RoutedEventArgs e)
{
using( var db = new EShopDataContext() )
{
this.DataList.DataContext = db.Customers.Take(10).ToList();
}
}És már készen is vagyunk, el lehet indítani, lehet csodálkozni vagy borzonkodni a gagyi adatlistánkon. Hogy ne hányja tele a képernyőt csak az első 10 rekordot kéri le a fenti kód. Ha az összes kell, egyszerűen töröld ki a Take(10)-et, viszont akkor úgy kell módosítani a layoutot is, hogy működjön a scrollozás.
Ha esetleg komolyabb adatkezelő projektbe fogsz, akkor a WPF-et a helyedben inkább hanyagolnám és maradnék WinForms alatt, ott használható az ArchElf által emlegetett DataGridView is, azt meg úgy szabhatod testre, ahogy tetszik.
-
#849
Gregorius
őstag
babyanigirl
#847
Gregorius
őstag
válasz
babyanigirl
#847
üzenetére
És meddig jutottál?
-
Gregorius
őstag
A dolog ennél sajnos súlyosabb. WPF-ben nincs olyan, hogy DataGridView, de még a szimpla DataGrid is csak készül (Silverlightban már van). Az adatkötés is teljesen máshogy működik.
Yash:
Én a helyedben inkább a LINQ-kel barátkoznék, mert habár a mögöttes tartalom sokkal bonyolultabb, az alapozás és az egyszerű feladatok jóval könnyebbek, mint a DataSeteknél. -
Gregorius
őstag
Kérdés, hogy mennyire bonyolult excelt akarsz generálni. Ha elég egy sima, képletmentes, pucér táblázat, akkor a Microsoft.Jet.OLEDB.4.0 providerrel simán tudsz ilyet csinálni.
Kockázatok és mellékhatások: csak 32 bites programmal működik (vagyis explicit x86-ra kell fordítani, hogy x64-es rendszeren is x86 módban induljon el), ugyanis MDAC-ból nincs 64 bites. -
-
Gregorius
őstag
Aki esetleg lemaradt volna róla:
.NET Framework 3.5 (Offline telepítő a lap alján)
Visual Studio 2008 Team Suite (Trial)
Visual Studio 2008 Express Editions -
Gregorius
őstag
válasz
andriscs
#583
üzenetére
Az a rossz hír, hogy logoff-ot ezen a módon csak olyan processz kezdeményezhet, ami egy interaktív szessönben fut (vagyis egy belépett júzer alatt, aki nyomkodja a képernyőt). Átlag ember átlag service-e nem ilyen. Process futtatása helyett egyébként nyugodtan lehetne az ExitWindowsEx-et használni (bár a fenti probléma erre is érvényes):
[DllImport("user32.dll")]
static extern bool ExitWindowsEx(uint uFlags, uint dwReason);
...
ExitWindowsEx(0, 0); // Logoff
... -
Gregorius
őstag
Nem értem mivel érdemeltem ki ezt a hangnemet.
Most minden rosszallás nélkül, és egyébként se vedd zokon, de ha programozni akarsz, akkor a sorrend: kútfő, help/MSDN, gúgli és csak azután jön a fórum.
Mivel ezt a nyelvet teljesen autodidakta módon tanulom és gyakorlom
Méginkább érvényes a fenti. A helpet meg kell tanulni használni, önerőből máshogy nem megy.
Tök jól meg is csinálja a html fájlt, de ha megnyitom böngészővel, akkor az ékezetes betűk helyén olvashatatlan karakterek vannak
A StreamWriter az default UTF-8 kódolású fájlt csinál (byte order mark nélkül), az IE pl. meg default az ANSI kódlappal próbálja ezt megnyitni (ha nincs BOM). Úgyhogy egy ilyet bele szokás ilyenkor rakni a html header-be:
<meta http-equiv=''Content-Type'' content=''text/html; charset=utf-8'' />
Vagy a StreamWriter-t állítod be ANSI-ra-ra:
new StreamWriter(File.Create(saveFileDialog1.FileName), Encoding.Default); -
Gregorius
őstag
válasz
andriscs
#388
üzenetére
És a kedvenc alkalmazásodnak állandóan ott kell figyelnie a desktopon? És ha igen, akkor miért kell topmost-nak lennie?
Annak elkapása, hogy valaki épp teljes képernyőre vált az minimum ronda és csúnyán néz rád a fordító, egyébként nagyjából annyiból áll, hogy hook-kal elkapod az új ablak létrejöttének eventjét, majd ellenőrzöd, hogy az új ablak full screen-e (általában akkor az, ha borderless és topmost). Szóval WinAPI-ra fel.
[Szerkesztve] -
Gregorius
őstag
StreamReader-rel beolvasod soronként, majd String.Split()-tel szét tudod nyesni whitespace-ek mentén, vagy tetszés szerint. Akkor van ciki, ha túl hosszúak a sorok, ez esetben az az üdvözítő megoldás, ha egy MemoryStream-szerűségben buffereled a beolvasott adatokat, majd ahogy kipotyognak a szavak, trimmeled az elejét.
-
Gregorius
őstag
Semmi. Click után ellenőrzöd, hogy van-e, és ha nincs, akkor kiválasztasz egyet.
Nem vagyok túl ismerős a TreeView környékén (elég bugos kontrol, nem használtam túl sokat), de kell lennie valamilyen Selected property-nek vagy hasonló metódusnak rajta, vagy valamelyik TreeNode-on.
[Szerkesztve] -
#343
Gregorius
őstag
whitewolf5
#342
Gregorius
őstag
válasz
whitewolf5
#342
üzenetére
Öhmm. A közvetlenül az oszlophoz való hozzáférés általában tervezési hiba, merthogy nem izolálja megfelelően az alkalmazáslogikát meg a megjelenítést. Ilyenkor szoktam emlegetni, hogy mi van, ha felveszel még egy oszlopot, vagy átrendezed őket? Jól tervezett appnál ilyenkor a meglévő kódon nem kell módosítani.
-
#341
Gregorius
őstag
whitewolf5
#340
Gregorius
őstag
válasz
whitewolf5
#340
üzenetére
Így nem szebb/jobb/gyorsabb?
CASE WHEN Raktár IN (1,2,9,13,15,17) THEN...
Amúgy meg a WinForms-os DataGridView-ben vaon olyan tulajdonsága a binding-nek, hogy (null) érték esetén mit írjon be. Asp-ben ilyen nincs?
[Szerkesztve] -
#300
Gregorius
őstag
whitewolf5
#299
Gregorius
őstag
válasz
whitewolf5
#299
üzenetére
Az SQL Server Express az a VS-től függetlenül telepíthető, ráadásul még ingyen is van, és ahol hosztolnak asp.net-et, ott jó eséllyel sql-t is lehet találni.
Ha mégsem sql alapon akarod a műsort, akkor asszem egy új providert kell implementálnod és belekonfigolni az asp.net-be. Bár loginnal olyan túl sokat még nem foglalkoztam.
Talán ez segít: [link] -
#298
Gregorius
őstag
whitewolf5
#297
Gregorius
őstag
válasz
whitewolf5
#297
üzenetére
Az adatbázisfájlokat ott kell hagyni, ahová az mssql megcsinálta.
Az IIS-en nem kell beállítani különösebben semmit, legfeljebb annyit, hogy adott application pool-hoz hozzárendelni, de ha már csatlakozni akar az mssql-hez, akkor jól van beállítva.
A hibaüzenetből ítélve pedig rossz a connection string a web.config-ban, nem találja a megadott mssql szervert. Vagyis (egyelőre még) nem a loginnel van baj.
[Szerkesztve] -
#296
Gregorius
őstag
whitewolf5
#294
Gregorius
őstag
válasz
whitewolf5
#294
üzenetére
Amikor a webszerveren futtatod, akkor nem ugyanazokkal a jogosultságokkal fut az oldal, mint amikor VS-ben. Utóbbi esetben azzal a júzer account-tal fut, amivel bejelentkeztél (az esetek zömében rendszergazdaként
), az IIS viszont az IWAM_<gépedneve> júzer nevében futtatja az oldalt, szóval ezt a júzert a megfelelő jogokkal hozzá kell adni az SQL-t elérni jogosultak köréhez, és az adott adatbázison felvenni a db_datareader illetve a megfelelő role-ba. -
Gregorius
őstag
A jelenlegi infrastruktúrába csinálhatsz egy webservice szerű dolgot php-ben, de akkor pont a VS-t küszöbölöd ki a rendszerből, merthogy ilyenkor a feladat zömét a php végzi el.
A legegyszerűbb VS-es megoldás az volna, ha egy saját masinát beállítasz a datacenter-be, ami majd asp.net oldalt fog kiszolgálni (vagy keresel egy másik szolgáltatót pl. [link]), persze ekkor a WinForms-t dobtad, de legalább nem kell telepíteni a kliensszoftvert.
Ha mindenképpen WinForms, akkor a szerverre lehet webservice-t írni, ami gyakorlatilag csak annyiban különbözik az asp.net-es megoldástól, hogy nem ember által oldasható html oldalt, hanem gépi feldolgozáshoz strukturált adatokat ad ki magából, de az alkalmazáslogika 90%-a még mindig ebben van. -
Gregorius
őstag
Naszóval.
Errõl én nem tudtam![;]](//cdn.rios.hu/dl/s/v1.gif)
Úgy értettem, hogy ahol maradéktalanul tudsz .NET-es programot futtatni, ott MSSQL-t is fel tudsz tenni.
Ja és ugye nem biztos, hogy azt is meg akarja venni...
Az MSSQLEx Ingyen van.
ahol fut a .net 2.0, ott azt valaki direktbe felrakta, mert kellett neki vagy
a visual studio 2005-tel együtt került fel, ahol a telepítő automatikusan rakta fel.
Vagy ingyen és bérmentve letöltötte MS-től ([link]) és úgy rakta fel.
Mellesleg az MSSQL2005 felrakja magával a .NET 2.0-t is.
mert egyébként én sem vagyok hülye és nem szivatnám magam egy alig támogatott adatbáziskezelővel.
Van egy sajnálatos hírem: ahol a .NET a trendi, ott a MySQL az alig támogatott, ahol meg az utóbbi a bevált, ott meg szarnak a .NET-re.
igenis ki lehet rakni, sőt ki is van rakva a mysql a netre, ajánlom a figyelmedbe:
Értelmes szolgáltatóval nem nagyon találkozni, amelyik a localhost kivételével más gépről is közvetlenül elérhetővé tette volna a MySQL-jét (ez biztonsági okokból van így). Márpedig ha csak a localhost-ról éred el, akkor ugyanitt kellene futnia az adatlekérő kódnak is, amiből el akarod érni az adatbázist, vagyis jobb esetben windows-on kell hogy hosztoljanak hozzá, amire az ember általában igen csúnyán néz (főleg ha nem dedikált szerverek vannak, kicsit körülményes a rendes izolációt megcsinálni a különböző tárhelyek között, nem is sokan vállalják el).
Szóval vagy átvered a kedves üzemeltetőn, hogy márpedig neked külsö kapcsolat kell a MySQL-hez (hozzáteszem szerény véleményem szerint nincs olyan agyatlan barom a világon aki közvetlenül kirak egy adatbázisszervert az internetre a legkisebb rosszérzés nélkül), vagy elfelejtheted a .NET Connectort és írhatsz helyette egy kellemesen csúnya adatelérő wrappert, amivel ugyanúgy biztonsági problémák vannak. Az meg egy vizsgáztató rendszernél nem jó dolog, hogy a furfangos tanuló betör a rendszerbe és átírkálja a saját eredményeit.
[Szerkesztve] -
Gregorius
őstag
válasz
Terminus_
#278
üzenetére
Hát szerintem az ECMA az, amihez utoljára nyúlj. Egyrészt az csak a nyelv specifikációja, másrészt konkrét példákból hamarabb meg lehet tanulni a szintaxist.
A könyvben sajna nem tudok segíteni, a 2.0-hoz készült irodalmat nem ismerem, az 1.1 óta pedig pont az ASP.NET-ben történt a legtöbb változás. -
Gregorius
őstag
válasz
Terminus_
#276
üzenetére
Két hét alatt? Az húzós lesz, és ezt nyugodtan megmondhatod a főnökségnek is. Ennyi idő még az osztálykönyvtárak minimális ismeretéhez is igencsak kevés, úgyhogy inkább azt tudom mondani, hogy a .NET belső lelki világával, a CLR-rel (assembly, JIT, GC), meg az alapvető nyelvi elemekkel (property, event, delegate) foglalkozz, mert azt kizárt, hogy a helpből könnyedén meg lehetne tanulni. Amit viszont az osztálykönyvtárból mindenképpen alapos áttanulmányozni az a System.Collections, mert ez gyakorlatilag minden programban előfordul, ami a Hello World!-nél hosszabb.
Amúgy milyen feladatkörben kellene használni? Mert akkor esetleg afelé lehet orientálódni a tanulásban is. -
Gregorius
őstag
A DataSet/DataTable az egy struktúrált adathalmaz. Hogy ezt adatbázisból töltöd fel vagy szövegfájlból vagy kézzel, az már rajtad múlik.
Ha nincs szükséged a DataTable szolgáltatásaira (rendezés, keresés, indexelés, változáskezelés), akkor kicsit több munkával de lényegesen gyorsabb és kevesebb memóriát zabáló megoldást kapsz, ha egy saját class-t implementálsz, azt pakolod bele egy BindingList<T>-be, és ezt adod meg DataSource-nak, igaz ez sokkal kevesebbet tud. A DGTextBoxColumn, stb... ugyanúgy működik. -
Gregorius
őstag
Ha minden igaz, leválasztották magukról a devenv fejlesztő üzletágukat. Hogy ténylegesen el is adták, vagy csak átcsoportosítás volt, az jó kérdés.
Mindenesetre az biztos, hogy a Borland a fejlesztőeszközeivel minimum egy éves lemaradásban van, az pedig ezen a téren nagyon nagy idő. -
-
#226
Gregorius
őstag
Vilmoskorte
#225
Gregorius
őstag
válasz
Vilmoskorte
#225
üzenetére
Ha nem hozta, akkor marad az admin. Ez van. Nem hiszem, hogy éveket szeretnél azzal tölteni, hogy egy rakás COM objektum meg registry bejegyzés jogosultságait állítgatod.
A full image-es telepítő amúgy asszem nem nyaggat, hogy regisztráld. -
#224
Gregorius
őstag
Vilmoskorte
#223
Gregorius
őstag
válasz
Vilmoskorte
#223
üzenetére
A Debugger Users csoporthoz add hozzá magad.
Amúgy meg várjuk már az SP1-et (Q3 2006), mint a messiást. Nekem ma egy órán belül kétszeri ''Visual Basic Compiler has encountered an error...'' után úgy borult meg az egész, hogy minden szép és jó, amíg egy DataAdaptert meg nem kísérelek konfigurálni, amit egyszerűen megtagad a Studio mondván a projekt nem létezik, és utána arra hivatkozik, hogy a referencia (System, System.Windows.Forms, stb...) által mutatott fájlt nem találja.
Úgyhogy most szépen lefekszem, holnap reggel meg előveszem a telepítőcédét.
[Szerkesztve] -
Gregorius
őstag
válasz
andriscs
#220
üzenetére
GUI-nak nem szokás külön szálat indítani, GUI szálat Sleep-pel várakoztatni meg végképp nem. Én a helyedben inkább azt csinálnám, hogy a spash screen-re felraknék egy 2000ms-re állított timer-t, majd amikor az lejár, akkor bezárnám a splash-t. Első körben. Ha közben még dolgoztatni akarod a rendszert, akkor még lehet kicsit bonyolítani, de alapnak ez így jó.
splash.ShowDialog();
Application.Run(new MainForm());
//...
splash_Load(...)
{
this.timer1.Start();
}
timer1_Timer(...)
{
this.timer1.Stop();
this.Close();
} -
#218
Gregorius
őstag
paramparya
#216
Gregorius
őstag
válasz
paramparya
#216
üzenetére
Ha mindig ugyanaz kell, akkor a TabIndex-eket úgy kell beállítani, a legelső index lesz az aktív majd növekvő sorrendben lépked végig. Ha változtatni akarsz, akkor pedig TextBox.Focus()
-
Gregorius
őstag
Háát, azt esetleg meg lehet játszani, hogy a webservice-edben perzisztens gyűjteményt használsz (értsd: nem kéred le az egész dataset-et újra minden hívásra), és az egyes method-ok külön táblákat adnak vissza ebből, akkor több objectdatasource-ból összeszedheted az adatokat. Persze hogy ez így működik-e... Igazság szerint nem nagyon foglalkoztam még bővebben asp.net-tel.
-
Gregorius
őstag
Ha jól érzékelem, azt akarnád csinálni, hogy egy WebService összerak neked egy DataSet-et és azt akarod egy oldalon többrendbelileg megmutatni. Nekem nagyon úgy tűnik, hogy az ObjectDataSource nem támogatja. Helyette ezt lehet írni a Page_Load-ba:
TesztDS ds = new WebService().GetMyData();
this.GridView1.DataSource = ds;
this.GridView1.DataMember = ''TesztTable1'';
this.GridView1.DataBind();
this.GridView2.DataSource = ds;
this.GridView2.DataMember = ''TesztTable2'';
this.GridView2.DataBind(); -
Gregorius
őstag
Egyszerű láncolt listát akarsz csinálni?
Arra már van kész komponens: LinkedList<T>. Mondjuk ez duplán láncolt, és pár tíz bájttal nagyobb az állapota, mint szükséges volna.
Esetleg jó lehet a List<T> is, ezzel csak az a baj, hogy ha a közepére/ből szúrsz be/veszel ki egy-egy elemet, akkor az egész listát lemásolja (a berakott/kivett elemmel/nélkül), és ez kellemesen lassú tud lenni.
Feladattól függően esetleg a Queue<T> és a Stack<T> is hasznos lehet.
Amúgy meg nem kell hozzá unsafe, mert referenciákkal is ugyanolyan láncolt listát lehet csinálni, mint C-ben.
class LáncoltLista<T>
{
public LáncElem<T> Első = null;
public void Eléfűz(T érték)
{
LáncElem<T> le = new LáncElem<T>(érték);
le.Következő = this.Első;
this.Első = le;
}
}
class LáncElem<T>
{
public T Érték;
public LáncElem<T> Következő;
public LáncElem(T érték)
{
this.Érték = Érték;
this.Következő = null;
}
}
A T helyére meg olyan típust írsz, amilyen tetszik. Például
LáncoltLista<Point> pontLista = new LáncoltLista<Point>();
pontLista.Eléfűz(new Point(12,25));
... -
Gregorius
őstag
static int steps = 20;
static Thread[] workers = new Thread[10];
static void Main( string[] args )
{
for( int i = 0; i < workers.Length; i++ )
{
workers = new Thread(new ParameterizedThreadStart(Worker));
workers.Start(i);
}
for( int i = 0; i < workers.Length; i++ )
{
workers.Join();
}
Console.WriteLine(''--Készen van--'');
}
static void Worker( object arg )
{
int id = (int)arg;
for( int i = 0; i < steps; i++ )
{
Console.WriteLine(''Dógozom #{0}: {1}'', id, i);
}
}
Ha arra az egymásbaágyazott for ciklusos megoldásra gondolsz, ami különböző lépésközzel végigmegy az egész tömbön egymás után, akkor sajna az a tényállás: az egyszálú esetben jobban optimalizálható az előző pass-ok eredményeinek felhasználásával.
[Szerkesztve] -
Gregorius
őstag
-
Gregorius
őstag
Szerintem jobban jársz, ha globálisan csinálod meg, nem egyenként minden control-ra.
Ehhez először el kell kapni a billentyűleütéseket a Form-on:
this.KeyPreview=true;
Aztán lereagálni a KeyDown/KeyPress események valamelyikét. A KeyDown finomabban hangolható: az alábbi működik Enter-re, de pl. Shift-Enter-re már nem reagál.
private void Form1_KeyDown( object sender, KeyEventArgs e )
{
if( e.KeyData == Keys.Enter )
{
e.SuppressKeyPress = true;
this.SelectNextControl(this.ActiveControl, true, true, true, true); //A SendKeys-t nem szeressük
}
}
Egy apró pici részletet még nem szabad elfelejteni: ha a Form-on van AcceptButton (Form.AcceptButton=...), akkor az mindenképpen ellopja az Enter-t bármelyik Control-ról, akármit is csinálsz. -
Gregorius
őstag
Ha írtál már valaha önerőből on-demand lexikai- és szintaxiselemzőt, ez sajna nem a tíz soros ''Hello World'' kategória (ráadásul atomra ki van optimalizálva), és őszintén szólva kétlem, hogy bárki bármilyen tapasztalattal képes lenne két napnál hamarabb megoldani (még ha tökéletes a dokumentáció, akkor sem), kivéve ha az illető az azon a kódrészen dolgozó csapatban van.
Ez idáig rendben van, csak azt nem értem, hogy melyik balf*** tolta hónapokkal egy stabil változat előtt piacra a VS-t?!
a bugfixeket service-packokba gyujtse azonnali relase helyett. van ennek valami oka is a tradicion kivul?
Kevesebb verzióval kell foglalkozni, ha összeakad valamivel az egyik javítás.
nem nagyon latom, hogy akarmelyik kereskedelmi IDE hasonlo utemben tudna bugfixeket kozzetenni, mint egy opensource project.
Ezt majd akkor fogadom el érvnek, ha mondjuk a NetBeans vagy az Eclipse sebességben és memória-hatékonyságban utoléri a Visual Studio-t. Akár a 2005-öst, pedig az nagyságrenddel lassabb, mint a 2003 (szintén ''bug''). -
-
#157
Gregorius
őstag
paramparya
#156
Gregorius
őstag
válasz
paramparya
#156
üzenetére
Mármint midi port, vagy zenélni akarsz?
Előbbi esetben max interop jöhet szóba a win32 API-val, utóbbi esetben Managed DirectX, azon belül DirectMusic alapos tanulmányozása. (egyébként meg egyáltalán nem értek hozzá ) -
Gregorius
őstag
Az ultimate mitírki
class _
{
enum ___{_,___,_____,_______,________,______,____,__}
static ___ __(___ _,___ __)
{
return (___)(_|___.___|__);
}
static void Main()
{
___ _ = _.__(___._____|__(___.___,___._____),___._____);
Console.WriteLine(_);
}
}
Teljesen legális C# kód, ki lehet próbálni. Épp a nyelv specifikációját böngésztem, úgy tűnik, a srácok úgy gondolták, hogy jó ha ilyet is lehet csinálni
[Szerkesztve] -
Gregorius
őstag
válasz
andriscs
#138
üzenetére
Éppen a nyomtatást próbálom leprogramozniC# alatt, és kisebb gondom akadt. Miután beolvastam egy szöveget egy richtextbox-ba, és kirakom a nyomtatási képet, akkor a drawString metódus
Hadd mutassalak be a ReportViewer-nek: [link] [link]
A GDI-s DrawString-es megoldást pedig nyugodtan el szabad felejteni. Jah, a DrawString nem fog neked formázott szöveget rajzolni.
Valaki csinált már közületek többszálas progit?
Ja. Nem volt egy leányálom.
Elvileg jól beírtam a tutorialos példát, de mégsem képes a formban létrehozott szál meghívni a formban megadott eseménykezelőket (gyakorlatilag nincs kommunikáció a gyermek- és a szülő szá között)...
Kód?
Másik kérdésem: openGL-t be lehet valahogy üzemelni C# alatt?
Utoljára ezt használtam: [link] Balra a menüben a BaseCode alatt lehet válogatni. -
Gregorius
őstag
Nah beleolvastam.
Aszongya a 7. pontban
this paper examines only stop-the-world, non-incremental,
non-concurrent garbage collectors.
Kár, hogy a .NET GC és az újabb Java cuccok nem ilyenek.
If their applications will be deployed on
systems with at least three times as much RAM as needed
Megmondom őszintén, olyan rendszert még nem nagyon láttam (az otthoni játékpc-ket kivéve), ahol átlagosan a RAM több, mint 50%-a ki lett volna használva. Ökölszabályként is ezt használják rendszerméretezéskor.
De ha már mégis fogytán a RAM, nem csoda, hogy a garbage collection szarul teljesít, lévén egy csomó szemét kikerül a pagefile-ba ahelyett, hogy a rendszer engedné előtte a GC-nek begyűjteni. (A bookmarking collector-juk, ami figyelembe veszi ezt a paging-et, állításuk szerint alig veszít a teljesítményéből nagy memóriaterhelés esetén) -
Gregorius
őstag
Amint hazaértem, elolvasom, csak RDP-n keresztül kicsit komplikált
Addig egy kérdés: csinálok egy setup&deployment projektet (jelenleg a VS2005RC1-ben, mert úgy tűnik, a 2003-asom megadta magát és nincs kéznél az install CD, de látszólag ugyanaz). Hogyan tudok olyat csinálni, hogy telepítés után minden egyes júzer bejelentkezésekor elinduljon egy konfigurációs lépés? Arra volna szükség, hogy ha a júzer a telepítés óta először jelentkezik be, akkor az Application Data mappájába bekerüljön néhány fájl. Ezt meg tudja oldani a VS-féle setup projekt, megoldható-e custom step-pel, vagy nézzek valami komolyabb megoldás után?
Egy meglévő programot wrappelek msi-be, hogy lehessen távtelepíteni, úgyhogy magát a programot nem tudom módosítani.
), az IIS viszont az IWAM_<gépedneve> júzer nevében futtatja az oldalt, szóval ezt a júzert a megfelelő jogokkal hozzá kell adni az SQL-t elérni jogosultak köréhez, és az adott adatbázison felvenni a db_datareader illetve a megfelelő role-ba.![;]](http://cdn.rios.hu/dl/s/v1.gif)
Úgyhogy most szépen lefekszem, holnap reggel meg előveszem a telepítőcédét.
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
Állásajánlatok
Cég: FOTC
Város: Budapest