- Samsung Galaxy A55 - új év, régi stratégia
- Sony Xperia 1 V - kizárólag igényeseknek
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Fotók, videók mobillal
- MIUI / HyperOS topik
- iOS alkalmazások
- Samsung Galaxy Z Flip5 - ami kint, az van bent
- iPhone topik
- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy Z Fold5 - toldozás-foldozás
Hirdetés
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Nyár végén jön az idei THQ Nordic Digital Showcase
gp Az új bejelentések mellett újabb részleteket kapunk a Gothic Remake-ről és a Titan Quest II-ről is.
-
A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
ph A vállalat többek között egy slim profilos léghűtővel, egy helytakarékos táppal és egy ITX-es házzal adott magáról életjelet.
Új hozzászólás Aktív témák
-
Livius
őstag
válasz ReSeTer #9681 üzenetére
Szerintem ez arra utal, hogy ha csinál valaki egy C# osztályt, és azt egy DLL-be buildeli majd tovább adja azt akár pénzért, ilyenkor valóban a user egy másik programozónak tekinthető aki azt majd a saját C# programjában felhasználja. A fejlesztő "user"-től van elrejtve az amihez jobb ha nem nyúl hozzá.
[ Szerkesztve ]
Gigabyte GA-Z170-D3H, Intel Core i7-7700K, Corsair Vengeance 2x8GB DDR4-3600MHz, Intel 545s 256GB SSD, EVGA GeForce GTX 1060 GAMING 6GB
-
válasz ReSeTer #9681 üzenetére
"aki hozzá akar férni" Ennek a korrekt megnevezése az "Client" vagy "Client code" és semmi köze sincsen a végfelhasználóhoz vagy bármilyen személyhez. Magyarul azt jelenti, hogy a hívó fél, a hívó oldal.
Ha deklarálsz egy interfészt vagy egy( publikus osztályon egy) publikus metódust, konstruktort akkor az kívülről látható lesz, tehát lesz olyan kód, ami látja a publikus metódust és fel akarja hívni. Ebben a relációban a publikus metódust hívó kód a "Client" és ami belül van (számára láthatatlan) az az implementációs részlet.
Amikor Te felhívod a System.Console.WriteLine(...)-t, akkor abban a relációban a Te kódod (vagyis nem te hanem a Te kódod) a kliens. Belül meg lehet hogy hegyek mozognak, Te pedig csak annyit látsz, hogy megjelenik a szöveg a konzolon, vagy ahová a kimenet mutat.
..Egy user általában felületen keresztül vezérli a programot...
A koncepciónak tökéletesen semmi köze nincsen a végfelhasználóhoz.A hívó kód - hívott kód koncepció minden szinten értelmezhető. Minden egyes fgv-hívásnál van egy hívó fél és van egy hívott fél. (tehát assembly-n belül is értelmezhető)
Röviden az implementiációs részletek elrejtésére szolgál a dolog. A hívó félnek minnél kevesebb dologgal kelljen törödnie ahhoz, hogy igénybe tudja venni egy publikus interfész/metódus által nyújtott "szolgáltatásokat".
A bővebben érdekel, akkor erről könyveket írtak.
Pld ezt tudom ajánlani:
Amazon.com: Adaptive Code: Agile coding with design patterns and SOLID principles (Developer Best Practices) eBook : McLean Hall, Gary, Hall, Gary McLean: Kindle Store[ Szerkesztve ]
-
válasz ReSeTer #9686 üzenetére
A végfelhasználónak meg egyéb személyeknek semmi köze a koncepcióhoz.
Néhány ezer sor fölött már fontos tényező, hogy a bonyolúltságot elrejtsd / leválaszd egy megfelelő osztályba/komponensbe és annak felhasználási pontján már csak néhány egyszerűen használható tiszta interfészt látszódjon.
Ez akkor is igaz, ha te írod az egész szoftvert.
Különben hamar spagettivé válik az egész. Ha többen fejlesztik a kódot, akkor ez fokozottan érvényes. Ha fel kell használnod egy létező , működő komponenst, akkor jó esetben elég megnézned a publikus interfészeit és jó eséllyel rájössz hogyan kell használni, felhívni.
Ha minden publikus lenne, akkor az egész kódot át kéne nézni ahhoz hogy használni tudd.[ Szerkesztve ]
-
cattus
őstag
válasz ReSeTer #9686 üzenetére
Az előttem hozzászólót kiegészítve, nem feltétlen érdemes elrejteni egy komponens belső állapotát, mert "titok", hanem pl. mert az állapot változtatását szeretnéd bizonyos feltételhez kötni (pl. egy belső számérték nem mehet bizonyos szint alá, mert annak az adott kontextusban nincs értelme). Ha ezt nem tennéd meg, a programod bármely pontján keletkezhet bug, amit utólag nehéz kijavítani. Persze lehet mondani, hogy "majd figyelek rá hogy ne történjen ilyen", de ez finoman szólva nem életbiztosítás.
Do the thing!
-
martonx
veterán
válasz ReSeTer #9692 üzenetére
Az excelből adat kinyerés C#-al eléggé tiszta ügy, van ehhez csomó nuget package. Ami itt izgi tud lenni, az a word sablon file-ba berakás, formázás.
De szerintem ehhez is vannak nuget package-ek, amikkel word file-t tudsz generálni. Legvégső esetben pedig OpenXml egy szabvány, semmi nem gátol meg abban, hogy bármit összerakj OpenXml-ben (kivéve, hogy k...va bonyolult ). Ekkor egyedül arra kell odafigyelned, hogy amit csinálsz az valami régi Office verzióval legyen kompatibilis pl. Office 2007-tel, mert az új Office-ok mind fogják tudni kezelni a régi file-t, de ha új verzióra lősz, akkor azt nem fogják tudni kezelni a régi Office-ok.Én kérek elnézést!
-
fatal`
titán
válasz ReSeTer #9695 üzenetére
Ha interopot integrálsz, akkor mindenhol ugyanannak az office verziónak kell lennie, mint, amit behúztál a projektbe (kivéve, ha webes projekt, akkor a webszerverre vonatkozik ugyanez).
Ráadásul, ha jól emlékszem, akkor az interop nem managed code.
Nem erőltetném ezt.
[ Szerkesztve ]
-
válasz ReSeTer #9695 üzenetére
A kód esetleg futhatna központi helyen, egy belső webszerveren, intranet oldalon?
-(1) felhasználó az oldalra navigál,
-(2) letölti az általad publikált "mester" excel templatet -ezáltal rá tudod kényszeríteni mindig a legfrissebb sablon használatára-. Mert nyilván a sablon is változni fog.
-(3) kitölti, feltölti egy formmal
-(4) szerver oldali kód az excel alapján valami wordot generál, azt letölti a felhasználóHa nem tartod kézben a környezetet és hogy mindig mindenki legfrissebb sablont használja, akkor az nagy kényelmetlenség lehet.
(ilyet officeos dolgot még nem csináltam lehet elkerülte valami a figyelmemet)[ Szerkesztve ]
-
sztanozs
veterán
válasz ReSeTer #9743 üzenetére
Próbálj meg tesztfeladatokat megoldani.
https://www.codewars.com/ például.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...
-
quailstorm
nagyúr
válasz ReSeTer #9743 üzenetére
Van egy magyar könyv, Evosoft alkalmazott írta. Szerintem ez elég jó alap.
#9745 Victoryus : megjelenítés rétegben mindegy milyen DB van alatta, szóval inkább általános adatbáziskezelős tutorialokat nézz, meg az accdb driver API kézikönyvét.
[ Szerkesztve ]
-
quailstorm
nagyúr
válasz ReSeTer #9754 üzenetére
Json, vagy XML.
INI egy rémálom, TXT meg 80-as évek.Találj ki valami jó kis objektumos reprezentációt, aztán szerializáció, deszerializáció.
DataContractTudom, hogy nem ez a legszebb megoldás, amit linkeltem, de ezt régi .NET-en is meg lehet oldani külső libek, NuGet és függőségek nélkül.
[ Szerkesztve ]
-
válasz ReSeTer #9754 üzenetére
Miért nincsen védve az excel vagy annak bizonyos részei a nem kívánt változtatásokkal szemben? Minden lapot/cellát védeni kéne ami az appnak bemenetéül szolgál.
Ha a programod függ a konkrét excel dokumentumtól, akkor ha képtelen vagy elérni azt, hogy ne barmolják szét a bemenetül szolgáló excelt, akkor azt is képtelen leszel elérni, hogy aki "szétbarmolja", az majd pontosan vezesse, hogy mit "barmolt" szét...
szerintem...
[ Szerkesztve ]
-
quailstorm
nagyúr
válasz ReSeTer #9761 üzenetére
YAML az van olyan egyszerű és letisztult, mint az INI, én azt javaslom ebben az esetben. De INI-hez is létezik library: például.
Én INI-vel úgy találkoztam, hogy GSD (PROFIBUS). Ahhoz képest a GSDML (PROFINET, XML alapú), az sokkal könnyebben használható programozás oldalról. INI-be nem tudsz szerializálni és deszerializálni sem (vagy kutatni kell olyan libet, ami tud).
-
válasz ReSeTer #9761 üzenetére
Azt az excel-t nem én irányítom, de ha változik is valami, általában csak annyi, hogy arrébb megy néhány oszlop, mert beszúrnak egyet, vagy törölnek egyet. Ez van.
Az excel a programod publikus API-ja. Ha a másik fél nem tartja magát hozzá, akkor a te programod sem tud stabilan működni. Ha a másik fél valamiért nem tudja magát fixen (legalább verziószerűen) az API-hoz tartani, akkor koncepcionálisan rosszul van kidolgozva az az API. -
válasz ReSeTer #9783 üzenetére
Erre azt írják, hogy rekurzívan (mélyen) klónoz:
OpenXmlElement.Clone Method (DocumentFormat.OpenXml) | Microsoft Docs[ Szerkesztve ]
-
sztanozs
veterán
válasz ReSeTer #9823 üzenetére
Nem fogja folytatni, mert ez egy dialógusablak (ShowDialog) - addig nem folyatatódik a kód futása, amíg az ablak be ne csukódik. Esetleg Timerrel tudod megoldani a dolgot.
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...
-
vlevi
nagyúr
válasz ReSeTer #9825 üzenetére
A ShowDialog feladata éppen az, hogy várjon a felhasználó reakciójára, és addig az alkalmazás más részét ne tudd elérni, amíg az a dialog ablak kinnt van. Más programnyelveken ezt ShowModal -nak hívják.
A Show() -ra kinn kellene maradnia, ott valami más dolog lehet, ami miatt bezáródik.
Mi lenne ennek a képernőnek a feladata? Mert, ha a nevéből ítélve csak egy progresbar szerű megjelenítés, ami kiírja, hogy hol jársz, arra nem kell külön formot létrehozni.
Sokféle megoldás létezik, arra, hogy kijelezd a futás állapotát a felhasználó számára. -
válasz ReSeTer #9827 üzenetére
Bontsuk kétfelé a kérdést. Vagy amit megértettem belőle:
1,
Akarsz valami UI-t csinálni, ami user inputra reagál, csinál valamit és visszajelzést ad.
Nem tudod hogyan kéne a UI-t létrehozni, strukrurálni, úgy hogy aztán később "egy másik metódustból" hozzáférj adott UI elemekhez?
UI-hoz nem szólok hozzá.2,
Van egy fő végrehajtási szálad és nem tudod hogyan kéne egy "jól definiált feladatot" nem a fő szálon végrehatjani hanem onnan a háttérbe delegálni úgy hogy a háttérben az megtörténjen, mellékhatásokat tudjon létrehozni, pld üzenetet tudjon küldeni vagy mondjuk meglegyen a visszatérési értéke?A "jól definiált feladatodat" ki kell szervezned. Legegyszerűbben egy metódusba amire aztán hivatkozni tudsz.
void Something(p1, p2, ..) { .. }
aztán ezt ahelyett hogy a fő szálon meghívnád ezt a Something(..)-et, delegálod a végrehajtását a threadpoolnak. Ezt a Task.Run(..) nal teszed meg és paraméterként átadsz egy delegate-et amelyik hivatkozik a metódusodra.
Tehát a fő szálon ahonnnan delegálsz :
p1 = ...;
p2 = ...;
var t = Task.Run(() => Something(p1, p2, ..))
// fő szál nincsen blokkolva, a 't' visszatérési érték referencia a Task objektumra amibe a delegált feladatod csomagolva lett.Ebben a példában a "Something" egy visszatérési érték nélküli metódus, tehát mellékhatásokkal operál.
Ha azt szeretnéd, hogy egy másik kódrészlet értesítést kapjon a "Something"-ben történtekről, pld hogy az éppen hol tart, akkor ezt a Something-nek átadott paramétereken kerszül tudod legegyszerűbben megtenni. Paraméterként átadsz egy delegate-et amit a "Something" fel tud hívni mintegy üzenve a külvilágnak.
pld átadsz neki egy Progress<T>-t paraméterként ezen keresztül pedig a Something vissza tud jelezni a Progress<T> gazdájának. (A Progress<T> egy Action<T> delegatet csomagol be, UI kompatibilis módon.)
Something(p1, p2, .., IProgress<int> progress)
{
progress.Report(0);Thread.Sleep(1000) // CPU work
progress.Report(50);Thread.Sleep(1000) // CPU work
progress.Report(100);
}[ Szerkesztve ]
-
quailstorm
nagyúr
válasz ReSeTer #9829 üzenetére
"Teljesen mindegy mi a method, az a lényeg, hogy nem UI-n belül lévő method-on belül akarom megváltoztatni az UI-n lévő feliratot."
Ilyet nem tudsz csinálni, amennyiben a számolás másik szálon történik. Ha csak egy változót akarsz pörgetni, arra tökéletes az IProgress. Egyébként pedig én callback eventet használnék és dispatcherrel vissza UI threadre (hogy a workerben ne legyen direkt UI kód).
Ha nincs több szál a dologban, akkor elég a sima event invoke és a callbackben meg UI elem setelés. De ha hosszabb számolás, és a UI-t nem szeretnéd fagyasztani, akkor jobban jársz a külön threaddel.
Eventek.
DispatcherFire/SOUL/CD mutatja a statikus elérését a UI elemnek, azt is lehet, viszont az nem szép és nem moduláris megoldás. Bedrótozod az egyik komponensbe a másik komponens struktúráját.
[ Szerkesztve ]
-
félisten
válasz ReSeTer #9829 üzenetére
Ez a példa a form1-en lévő button1 katt-ra megnyitja a form2-t, majd az azon található button1 katt-ra módosítja a form1-en a button1 feliratát. Az elv benne van, saját igényednek megfelelően átírod.
Form1.cs
namespace WinFormsApp3
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
Form2 MyForm2 = new Form2(this);
MyForm2.ShowDialog();
}
}
}Form2.cs
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
namespace WinFormsApp3
{
public partial class Form2 : Form
{
private Form1 MyForm1;
public Form2(Form1 MyForm1)
{
InitializeComponent();
this.MyForm1 = MyForm1;
}
private void button1_Click(object sender, EventArgs e)
{
MyForm1.Controls["button1"].Text = "PH! Fórum - C# programozás";
}
}
}Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
sztanozs
veterán
-
nagyúr
válasz ReSeTer #9964 üzenetére
Ha c# List-ről van szó, akkor a RemoveAt metódus eltávolítja a paraméterben megadott indexen lévő lista elemet a "helyével" együtt, tehát újra is méretezi a listát és az eltávolított elem utáni elemek indexe is változik természetesen. Ha eleve sorba voltak rendezve, akkor az a növekvő / csökkenő sorrend továbbra is megmarad.
Ú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!
- LEGO klub
- Samsung Galaxy A55 - új év, régi stratégia
- Napelem
- Milyen notebookot vegyek?
- Milyen billentyűzetet vegyek?
- HiFi műszaki szemmel - sztereó hangrendszerek
- Luck Dragon: Asszociációs játék. :)
- Sony Xperia 1 V - kizárólag igényeseknek
- Fujifilm X
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- További aktív témák...