Nézd, amíg nem mented el a file-t, addig szerencsétlen program nyilván csak az utolsó mentett állapotot fogja látni.

Egyébként nem tudom mit szeretnél, de valahogy háttal ülsz a lovon. Egyáltlán miért excel, és miért konzol app? Ha mindenképpen excel, és excelen belüli mentés nélküli cella változásokra akarsz reagálni, akkor arra az excel makró való.

De ha már mindenképpen ragaszkodsz ehhez az elcseszett felálláshoz, akkor ott a Visual Studio Tools for Office és az Excel.Application.SheetChange event, amire C#-ban fel tudsz iratkozni.

Én kérek elnézést!

Az excel automentés makrót már próbáltam. Sajnos túl sok idő amíg elmenti és kiolvassa a cella tartalmát, és ezt később még ki is kell küldenem soros porton.

Szeretném használni a személyes fejlesztési keretemet könyvvásárlásra. (Pluralsightom már van)

-(1) ASP Netcore.
Itt a Pro asp net core 2-t olvastam Adam Freeman-től pár éve, az anno nekem nagyon hasznos volt, de ahogy néztem nem nagyon újítja fel a példaprojektjeit, tehát szeretnék mást, most valami advancedebbet.

-(2) EF Core, Adatbázis, adatmodellezés témákhoz az aktuálisak közül melyek a legjobb könyvek?

-(3) Blazor / webassembly van már annyira stabil, hogy megérje kicsit beleásnom magam?
Ez utóbbi max érintőlegesen érdekel, de valamire el kell költeni a pénzt

[ Szerkesztve ]

Évek óta semmire nem költöm el a keretemet A kollégák meg full szar konferenciákra járnak csak azért, mert 3 nap szabadság, és végig lehet enni-inni, és legalább a keretüket is elköltik.

Én kérek elnézést!

Sajnos nem találtam még most sem megoldást hogy tudnám kiolvasni a cella tartalmát mentés nélkül. A gond az, hogy ez változik minden 0.5mp-ben. Így ha a mentést még bele rakom VBA scriptben akkor pár érték kimarad.
Az excelre viszont szükségem van, mert csak ezzel tud kommunikálni egy másik script.

Excel makro mindent IS tud. Ha a mentés ilyen gázos, akkor ne mentsd. Csak simán kapd el a cell változást, és hívd meg belőle a C# konzol appot. Persze ekkor meg erősen kérdéses, hogy minek a C# konzol app.

Illetve leírtam a tisztán C# megoldást is: "De ha már mindenképpen ragaszkodsz ehhez az elcseszett felálláshoz, akkor ott a Visual Studio Tools for Office és az Excel.Application.SheetChange event, amire C#-ban fel tudsz iratkozni."

Én kérek elnézést!

Erre gondoltam:

Azaz ez ilyen egyszerű. Nem kell mentegetni semmit. Majd maga az excel reagál, és megcsinálja, amit kell. Viszont ez már nem C# topik.

Én kérek elnézést!

Hmm ez eleg jo megoldasnak tunik. Szuksegem van egy c# programra ami kikuldi soros porton a cella tartalmat, mert az excel vba minden kuldesnel felepiti a sorosport kapcsolatot ami kb 1mp-et vesz igenybe.
Viszont nyitva tudom tartani vele a portot a c# szamara ami remephetoleg nem kivanja megnyitni ujra a kapcsolatot igy lentebb tudom tolni kicsit ezt a kesleltetest.

Az ablak Title szövegében szeretném kiírni a verziószámot. Itt írnak egy megoldásról , de mindég 1.0.0.0-át ír ki. A project Properties szerint a a Publish version: 1.0.0.7
Az XAML-be ez van:
Title="{Binding WindowTitle, RelativeSource={RelativeSource Mode=Self}}"
A kódban pedig
public string WindowTitle {
get {
Version version = Assembly.GetExecutingAssembly().GetName().Version;
return "MyTitle v" + version; }
}

[ Szerkesztve ]

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

És mi szerepel az AssemblyInfo.cs-ben?

Picard: "What we leave behind is not as important as how we've lived. After all, Number One, we're only mortal." Riker: "Speak for yourself, sir. I plan to live forever."

Jogos! Ott 1.0.0.0 szerepel. Vagyis a program által kezelt, és hogy én mit adok meg neki két különböző dolog?
A kérdésből is látszik mennyire vagyok képben

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

Egy új probléma lépett fel. Létrehozok egy időzítőt, ami 10 percenként meghívja az újrabeolvasó rutint.
    public partial class MainWindow : Window
    {

        public MainWindow()
        {
            InitializeComponent();
            
            // A program indulásakor beolvassa a táblázatot
            Read();
        // 10 percenként újra beolvassa
        DispatcherTimer dispatcherTimer = new DispatcherTimer();
        dispatcherTimer.Tick += new EventHandler(Reload);
        dispatcherTimer.Interval = new TimeSpan(0, 10, 0);
        dispatcherTimer.Start();
        }

Viszont nem tudom leállítani(elérni) egy másik függvényből? Mit csinálok rosszul?

[ Szerkesztve ]

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

Ne a konstruktorban deklaráld, hanem mint osztály változó, a függvényben létrehozott változók csak a függvényen belül érthetőek el

[ Szerkesztve ]

Köszi a gyors választ! Én is gondoltam már rá hogy rossz helyen van, de én még ZX81-en BASIC-en tanultam, ez a modern esemény alapú OOP elég ködös. Magyarul hova/hogyan tegyem át?

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

public partial class MainWindow : Window
{
DispatcherTimer dispatcherTimer = new DispatcherTimer();

public MainWindow()
{
InitializeComponent();

// A program indulásakor beolvassa a táblázatot
Read();
// 10 percenként újra beolvassa
dispatcherTimer.Tick += new EventHandler(Reload);
dispatcherTimer.Interval = new TimeSpan(0, 10, 0);
dispatcherTimer.Start();
}

Hálásan köszönöm!

Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews

Hat nem tudom, itthon annyira sok pythonos melo nem jön szembe.

Jó, én nem vagyok programozó, de a jelenlegi és az előző munkahelyemen is csinálgattam munkamegkönnyítő toolokat, mindegyik esetben C#-ban írtam őket. Itt most a jelenlegi cégnél (egy amerikai nagyvállalat) mindennél jobban preferálják a Pythont. Vannak kollégák, akik ismerik a nyelvet, így a toolokat most ők fejlesztik. A céges belső policy egyre jobban tiltja/üldözi a compiled exéket.

Mi a baj a binárisokkal? Digitálisan alá lehet őket írni.

[ Szerkesztve ]

Alapvetően nincs baj, de mostanság az a módi, hogy mielőtt a céges "szoftverboltba" bekerülnének ezek, a részlegünk egyik managere részéről átnézésre kerülnek a kódok (nem programozók), és csak ha jóvá hagyták, akkor mehetnek fel. Már eleve a rendszer úgy működik az utóbbi időben, hogy .py és hasonló (php, sh, ps1, stb) fájlokat fogad el, .exe-t nem. Bocs, de, elfogad mást is, de utólagos check jön, mielőtt a többi team membernek elérhetővé válnak. És azon a manuális check-en nem mennek át a binárisok.

[ Szerkesztve ]

Nálunk a cégnél mostanában kezdtek a C# mellé Pythonos Web Api-k bejönni. Egészen elképesztően kókány szarok a kódjaik (de legalább lassúak is), az Asp.Net Core-al összevetve.
Pedig én pl. a PHP-t kimondottan szeretem, Pythont is magamtól raktam a gépemre, hogy eljátsszak vele, azaz nem vagyok az a fanboy típus.
Szerintem mint nyelv, semmi gond nincs a gyengén típusossággal, tök jó a PHP, Python. Kis egyszerű konzol appokat, web api-kat összedobni bennük, data science-kedni (ami szintén nem programozás, maximum egy kis scriptelés), megtanulni programozni tök jók. Viszont komolyabb alkalmazásokat csak bolondok írnak ezekben.

Én kérek elnézést!

Nyilván az is a nagy előnye, hogy baromi elterjedt. Szerintem Windowson kívül ott van minden rendszeren preinstalled. Pl. a Pi-hez "tartozó" Raspbianon is out-of-the box ott volt a Python.

Ugyan Pi-re simán feldobtam a Mono-t, még package managerrel is simán megy a saját appom, de én informatikus vagyok, nem hiszem hogy egy mezei usernek ez menne bármilyen Linuxon.

Uppsz, sorry, ez nem válasz akart lenni

[ Szerkesztve ]

.net core-al is lehet már self contained appokat csinálni, nem kell telepíteni hozzá sehonnan semmit

Szerintem a python előnye az egyszerűsége, viszonylag könnyen össze lehet dobni hasznos dolgokat, a futtatókörnyezet jó eséllyel valamiért tényleg fel van telepítve.

Huhh, komolyan?
Na ezt ki kell próbáljam, és egy biztos érv a jó öreg .NET 4.5-tel szemben a .Net Core mellett.

Typescript rengeteget dobott a NodeJS-en, anélkül egykutya

Én kérek elnézést!

Srácok, biztos hogy nem látom a fától az erdőt, de az aszinkron programozással mindig meggyűlik a bajom

Az alábbi egy .Net Core Console application részlete.

A BackgroundWorker nélkül működik az alábbi, de nyilván ekkor lefoglalja a main threadet a microwebserver, ezt szeretném elkerülni. Tehát a program fusson tovább, a webserver meg szépen a háttérben. Mit rontok el?

Szerk: fene vigye el, megvan a hiba Lemaradt ez: bgw.RunWorkerAsync();, így már működik

class Program
{
static BackgroundWorker bgw = new BackgroundWorker();

static void Main()
{
Console.WriteLine("WebGUI Teszt");
StartWebGui();
Console.ReadKey();
}

static void StartWebGui()
{
var hostBuilder = new WebHostBuilder()
.UseKestrel()
.UseStartup<Startup>()
.UseUrls("http://localhost:808/")
.Build();

if (bgw.IsBusy == false) bgw.DoWork += (sender, e) =>
{
hostBuilder.Run();
};
}
}

[ Szerkesztve ]

Mi lenne a proper way helyette?

A lényeg: Raspberry Pi-n futtatok egy .Net 4.5 alapú servicet, ami különböző automatizálási feladatokat hajt végre, adott esetben, ha a feladat jellege megkívánja, az adatok MySQL adatbázisban landolnak (localhost). Az egyszerű webes felületnek két célja van: ha időm és energiám engedi, később lesz egy Androidos app is hozzá, ehhez szolgáltatna JSON API-t, másrészt jelenleg böngészőből érek el pár infót erről a service-ről, a Pi különböző paramétereit is. Szóval erre kell nekem, ezért választottam "rendes" webszerver helyett ezt a megoldást.

Mondjuk .Net Framework 4.5 helyett .Net Core 3.1-re váltani?

Én kérek elnézést!

Mi lenne a proper way helyette?

Nem vagyok biztos benne (*).
De első körben én megnézném, hogy Program.cs.Main()-ben egy új meztelen Thread-et létrehozva és azon indítva a WebHost-ot, hogyan viselkedik a webserver. De én a Thredeket sem szeretem

* Ami miatt bizonytalan vagyok, az az, hogy hogyan akarjuk/tudjuk kezelni a webservice esetleges chrashét. (egyáltalán akarsz-e ezzel foglalkozni):

Ha a background thread (ami a webservert futtatja) crashel (kezeletlen exception jön belőle) akkor érdemes lenne ezt az exceptiont valamilyen szinten elkapni, loggolni és vagy újraindítani a szervert vagy inkább az egész alkalmazást leállítani. Ez az egész opcionális, de alapvetően nem egészséges megadni az esélyét hogy egy bármilyen threadben kezeletlen exception ragadjon.

Ahogy nézem a BackgroundWorkeren van egy erre használható event: "RunWorkerCompleted" , az eventargs pedig: "RunWorkerCompletedEventArgs" ennek pedig van egy Error propertyje ami az esetlegesen elkapott exceptiont tartalmazza...

Ha Threadben gondolkodsz akkor jó pár alternatív opciód van amit mérlegelhetsz.

De én valószínűleg Task-ként futtatnám a webservert. A te esetedben nyilván az volt a "baj", hogy a WebHost.RunAsync() metódus által visszaadott Task-ot azonnal awaitelni akartad a fő száladon, így a fő programszál nekiállt async várakozni a Task elkészültére, ami ugye egy szervernél amíg le nem állítják nem fog megtörténni.

Ha a fő programszálad amúgy sem lép ki magától akkor szerintem a a WebHost.RunAsync() által visszaadott Task-ot sem kell nekiállnod awaitelni benne (ha tudod, hogy exception történt akkor érdemes) ettől függetlenül a viszakapott Task refernciáját nyilván elmented, hiszen ezen keresztül mindig tudod ellenőrizni az állapotát és szükség szerint awaitelve ki is tudod belőle szedni az esetleges exceptiont.

A fenti példában például a Console.ReadKey() blokkolja a fő szálat. Amíg a fő szál nem ért véget, addig a background threadeket (beleértve amelyek Task-ba vannak csomagolva) a runtime nem zárja be addiíg amíg azok nem fejezik be maguktól a futást.

[ Szerkesztve ]

Ezen már sokat gondolkodtam, de sok Nugetes motyóm nem kompatibilis vele. Pl. az SQLite (System.Data.Sqlite) sem, ARM-re nem volt 4.5-re sem, de oda simán fordítottam egyet az eszközön forráskódból. .Net Core-ra viszont eddig még nem sikerült.

(#9298) joysefke:
A Task-on már én is agyaltam, de amikor próbálkoztam, valahogy nem jött össze. Már nem emlékszem, hogy egy statikus metódussal gyűlt-e meg a baja, vagy azon aztán átlendültem és máshol akadtam el. Aztán végül a Bgwk lett az első, ami működött.

Sajnos nem vagyok programozó, csak egy lelkes amatőr, így ha valahol elakadok, hajlamos vagyok rövidebb utat választani Viszont a C#-ot szeretem, így néha olyan célra is ezt választom, ami szkriptnyelvből, Powershellből is megoldható lenne (melyekhez még a C#-hoz képest is kevésbé mozgok otthonosan).

[ Szerkesztve ]