Hirdetés
- Apple Watch
- Xiaomi 15T - reakció nélkül nincs egyensúly
- Kezünkben a OnePlus 15 és az Oppo Find X9-ek
- Vivo X300 Pro – messzebbre lát, mint ameddig bírja
- Xiaomi 15T Pro - a téma nincs lezárva
- 7000 mAh-s aksit kapott a Motorola Moto G57 Power
- Samsung Galaxy S24 - nos, Exynos
- Örömhír: nem spórol Európán a OnePlus
- iPhone topik
- Hivatalos a OnePlus 13 startdátuma
Új hozzászólás Aktív témák
-
pmonitor
aktív tag
válasz
ReSeTer
#10192
üzenetére
A ChatGpt-vel közösen készítettünk COM Wrappert a hozzá tartozó demóval együtt. A Wrapper Nuget-ben itt található.. Ehhez nem kell interop dll. A forrás repo itt található. A demó pedig itt van. A Wrapper-t és a demót is átnézed, akkor gyorsan rájössz a lényegre. "Csak" ismerni kell a Word objektumait. Ehhez segítséget itt találsz.
-
martonx
veterán
válasz
ReSeTer
#10140
üzenetére
Unit teszt is jó ötlet. Érted (vagy nem), de önmagában a class library nem futtatható, ergo nem debuggolható

Ez nem debuggolási kérdés, vagy hogy VS-t használsz-e.
Visual Studio Code is pont ugyanúgy megfelel a célnak. Egy console app-ba be kell referálnod, vagy egy unit tesztbe, vagy bármibe ami futtatható, és azon belül fogod tudni debuggolni, futtatni a class librarydet. -
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.
-
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";
}
}
} -
quailstorm
félisten
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.
-
joysefke
veterán
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);
} -
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. -
joysefke
veterán
válasz
ReSeTer
#9783
üzenetére
Erre azt írják, hogy rekurzívan (mélyen) klónoz:
OpenXmlElement.Clone Method (DocumentFormat.OpenXml) | Microsoft Docs -
joysefke
veterán
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. -
quailstorm
félisten
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).
-
joysefke
veterán
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...
-
quailstorm
félisten
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.
-
quailstorm
félisten
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.
-
joysefke
veterán
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) -
fatal`
titán
-
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. -
cattus
addikt
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.
-
joysefke
veterán
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. -
joysefke
veterán
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 -
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á.
Ú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!
- Apple Watch
- Víz- gáz- és fűtésszerelés
- Milyen egeret válasszak?
- Samsung Galaxy Felhasználók OFF topicja
- Xiaomi 15T - reakció nélkül nincs egyensúly
- Kormányok / autós szimulátorok topikja
- Jövedelem
- Itt a Valve GŐZGÉP — Steam Machine, mi vagy te? 🧐
- Ubiquiti hálózati eszközök
- Milyen asztali médialejátszót?
- További aktív témák...
- ASUS Zenbook S 13 OLED UM5302TA
- Swift SF16-51T 16" 3K OLED érintő Ultra 9 288V Arc 140V 32GB 1TB ujjlolv IR kam gar
- Sony Bravia XF85 43" 4K Ultra HD 100 Hz LED Android Smart TV (KD-43XF8577)
- MacBook Air 13", M3 16/256, csillagfény
- Kezdő Gamer PC / Számítógép! Csere-Beszámítás!R7 1700X /GTX 1060 6GB /16GB DDR4 / 250SSD + 1TB HDD
- BESZÁMÍTÁS! MSI B450 R5 5600X 32GB DDR4 512GB SSD RTX 3080 10GB RAMPAGE Shiva Cooler Master 750W
- BESZÁMÍTÁS! Acer Predator Helios Neo 18 Ai - Ultra 9 275HX 32GB DDR5 1TB SSD RTX 5070Ti 12GB W11
- Windows 10 / 11 Pro Retail aktiváló kulcs Azonnal szállítással, számlával, garanciával!
- OnePlus Nord 2T 128GB, Kártyafüggetlen, 1 Év Garanciával
- Eredeti DELL 240W töltők (LA240PM160)
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest

milyen UI?


