|
Hmm. I always thought background workers were 'outdated'. Seems to me that all you hear about these days is async/await.
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
Wood working tools are also "outdated" by that logic.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
You should generally avoid async void methods[^]. As per David Fowler's async guidance[^], you can either use Task.Run to push the execution onto a background thread, or call a Task -returning method and "discard" the returned task. Either option will allow exceptions to fire the TaskScheduler.UnobservedTaskException event[^] rather than crashing the application from the finalizer thread.
In this case:
internal class MainWindowViewModel
{
private MyEntity _data;
private async Task LoadData()
{
_data = await _repository.GETDataAsync();
}
public void WindowLoadedExecuted()
{
_ = LoadData();
}
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Okay, I don't think this is a rant, but there may be some ranting. I've been a developer for a very very long time (I won't say how long, but let's just say I used to use Borland OWL). I understand that languages and libraries progress, morph, and change over time. That is natural.
However, being someone that came from the days where you can drag a button onto a window, double click it and add the code (Forms), and when you want to modify it, you just do it in the editor, to this last application I am making using WinUI 3, which I find painful to make.
Is it just me, or have we taken a massive step backwards? Not having a GUI editor for making GUIs, and then having to download an application (WinUI 3 Examples) that shows how components and code need added, is just stupid to me. Not to mention that when you use panels, stack panels, grids and all that in XML, and then you realize you have to introduce another set of controls into an existing GUI....and see that it takes like hours of rework to get it not to be a mess again...WTF? Why are we moving in this direction? Not to mention, WinUI 3 seems wonky and lacking in performance relative the predecessors.
So, my general question is... Why does WinUI 3 bring to the table that is so good that you would abandon the ability to have a GUI editor, and hand jam everything in. This is no better than the first days of windows when we all had to make GUIs by editing the resource files.
So again. Why is Windows Forms falling out of favor, Why is WPF even being replaced by something that seems more obtuse?
I am going to build another App soon, and I would like someone to tell me why Windows Forms is not a good choice over WinUI 3.... Anyone?
Thanks.
|
|
|
|
|
I develop in WPF and (mainly) UWP. I have developed in Windows Forms. WinUI2 and WinUI3 look very similar to me. I use WinUI2 in UWP via a "using" to get some extra features that don't stand out in my mind at the moment. To use WinUI3, I have to do something I can't be bothered with for now.
I use the Visual Studio "GUI editor" in any case; prefering to work in XAML directly.
XAML (and UWP) is more "fun" for me than the alternatives. My app also "fits" on "mobile", tablet, PC, XBox and can run on ARM. My second choice would be WPF.
But you can do a lot with (any) .EXE these days.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I started programming before OWL existed (my first IDE was Turbo Pascal for CP/M on an Apple //e back in the early 80's).
I went through Pascal (OWL), C++ (MFC), and then C# (WinForms, and currently WPF). I refuse to code for WinUI, simply because I have no desire to learn it.
It took me a while to accept WPF (and I fought it HARD), but I find it easy to do (easier than WinForms in a lot of ways). I do all of my design work in the XAML editor (you can drag from the Toolbox pane to the XAML to get a new control on the page, and intellisense guides you when you start changing properties in the XAML, so it's not TOO bad).
After two years away from desktop apps, I spent the last weekend doing a WPF version (proof of concept) of our web app from work, and the hardest part was making the app allow the user to adjust font size with Ctrl+ and Ctrl- like a web browser (we have to comply with Section 508 by allowing the font in an application to be increased by up to 200%). A few years ago, I wrote a custom message box library that allows the developer to specify text size and custom colors (among other features), and with a little tweaking, my message boxes use the increased font size.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I can't find the setting(s) to change the color of a combobox within a datagridview.
I tried this code below. I get a dark line around the datagridview cell and a white background. I see the colors I set below when I view the list within the combobox.
combo.DisplayStyle = DataGridViewComboBoxDisplayStyle.ComboBox;
combo.CellTemplate.Style.BackColor = Color.LightSalmon;
combo.CellTemplate.Style.ForeColor = Color.Black;
combo.CellTemplate.Style.SelectionBackColor = Color.LightSalmon;
combo.CellTemplate.Style.SelectionForeColor = Color.Black;
modified 22-Sep-23 11:21am.
|
|
|
|
|
Microsoft have knobbled many features of quite a few controls (e.g. ProgressBar - we all prefer green! MonthCalendar - change the font to make it big enough to see - No!) and often the only thing you can do is to disable visual styles. That can be a problem though as some controls require visual styles to be on (e.g the Tile mode of the ListView).
However with the DataGridView the colour works in the way you desire when the FlatStyle of the ComboBoxColumn is set to either FlatStyle.Flat or FlatStyle.Popup. I guess they missed that.
|
|
|
|
|
|
Hello Everyone Myself Emmanuel Katto, I wanted to know what are Custom Control and User Control?
|
|
|
|
|
A User Control is built from existing controls: similar to a panel, you drop existing controls onto a blank canvas to create your own unique control.
A Custom Control is generally derived from an existing control, so you can extend its functionality rather than building from the ground up.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
... and user controls are generally easier to create than custom controls, and people often create custom controls when they don't need to.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
MY FIREBASE DATA IN VACCINE-ID-DATE-DETAILS
I WANT TO FIND DATA,IF I LOAD DATA TO DATA GRID VIEW1 AND DATA GRID VIEW2.AFTER I SELECT TWO DATE AND PRES FIND BUTTON I WANT SHOW THAT DATE BETEWEN DATE IN DATA GRID VIEW1 AND2
|
|
|
|
|
DON'T SHOUT. Using all capitals is considered shouting on the internet, and rude (using all lower case is considered childish). Use proper capitalization if you want to be taken seriously.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
sameera suresh bandara herath wrote: I WANT TO FIND DATA
Well, go ahead and do that. You have our permission.
Feel free to come back if you get stuck and have an actual question to ask, rather than a vague requirement to shout at us.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Steps
- Learn C#
- Learn basics of a database
- Learn how to access database from C#
- Learn how to code a UI.
- Learn how to do a range query for the database.
- Learn how to code that range query in C#.
- Put all of the above together to solve your problem.
|
|
|
|
|
You mean: C# and SQL.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Gerry Schmitz wrote: You mean: C# and SQL.
Me? My comment does say C#?
And although I was thinking about SQL I did mean just database in the first part.
But I also was not sure about what persistent data store they would be using. Their post did suggest something odd so I wanted it generic.
And re-reading I can see that the database is 'firebase' which is in fact a NoSQL database. So learning SQL is not appropriate in this case.
|
|
|
|
|
"Everything" I see dealing with Enums (in different name spaces) is lots of "recasting" to the underlying type or lots of namespace qualifying.
I needed to integrate "duplicate" Enums in different exe's and dll's that were "not the same" (or easily accessible) due to namespaces.
Now in my sender "POCO" I might have:
[DataMember]
public ServiceArm ServiceArm { get; set; } = ServiceArm.Undefined;
So I added to the POCO:
public string ServiceName => Enum.GetName( typeof( ServiceArm ), this.ServiceArm );
And in the consumer (different namespace; different exe / dll):
block.ServiceArm = Enum.Parse<ServiceArm>( unit.ServiceName );
No fiddling with namespaces; no obscure casting.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I may not be getting this correctly.
Are you trying to make use of several different independent enum definitions in different name spaces as if they were one, matching them on the enum name?
You can of course set up a demo to show that it works (today), but wouldn't it lead to a lot of maintenance problems, if the various enum definitions are updated independently of each other?
(I can't tell how much I miss a proper enum concept like the one we had in Pascal, where "underlaying type" was irrelevant: enums are not names of integers. They do not have any "underlaying type" but are literal values in the same sense as 'true' and 'false' in their own right as enum constants. 'using myEnumDefs' make these enum symbol available just like 'using myFunctions' make the function symbols available. But even programmers who never coded C/C++ seems to have adopted the idea that enums 'really' are integers with a name!)
|
|
|
|
|
What is an "interface"? I "tell" you a "valid" (Enum) "name" is the "interface" to the .exe / dll. And who tells who what to use? (I also happen to be serializing and deserializing)
The enum happens to be a handy implementation in this case.
The alternative is: a "standard" dll with "every" enum that anybody could possible need: creating one big dependency.
It also implies, I have to rewrite every exe / dll to "migrate out" every reference to this "master" enum into it's own dll.
(You had musing about a "universal language": this pattern can give different "names" based on context that "translate" to different enum values)
The whole "point" was to not have to muck with xxxx.aaa.xxx.ssss.ServiceArm, etc.
(If you don't code in C#, this is probably meaningless)
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
OK, I did not really intend to bemoan your use of the available facilities.
I was more focused on the lack of facilities, that could have been provided if C# had a proper enumeration type. So it was a sidetrack.
Now that C# does not provide a proper enumeration type, your workaround is fair enough. I am not happy with such workarounds being required, but I accept them - reluctantly.
|
|
|
|
|
What is a "proper" enum? The issue I'm addressing pertains to classes as well; which is "long namespaces".
You ignored the whole "central maintenance" issue.
If I had implemented it as a dictionary, would that have made a difference? No, just clumsier.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
The simpler solution for you is probably setting up an #include file with sequence of #define entries defining the proper constant names for you.
|
|
|
|
|
The actual translation in messaging layers should not be a significant problem.
Problems come about more because messages end up being modified far more than they should - probably because insufficient design or because there is no adherence to longer term roadmaps.
But if enums are a problem then move them, and only them into their own namespace (and dll.) Or redesign so static values are not used at all. That does of course trade strictness for ease of use.
|
|
|
|
|