Funking Giblet posted:

Figure out a different way to Populate your observable, and maybe, try not using an EF entity, but a DTO of some sort.

hackbunny posted:

For want of a proper Windows thread, I'll ask here: how would you write a UI for a Windows desktop application? My coworker wants to use Windows Forms but hasn't it been obsolete for a long time? Not that I know much about UI development on Windows...

NEED MORE MILK posted:

yeah i just started building my first large app in WPF and its super annoying if youre used to winforms but once you get the hang of it things start to come together really nicely

bindings and XAML reduce the amount of UI code by absolutely obscene amounts. there's a lot of annoying boilerplate code though

what im struggling with now is figuring out how the hell to get my ViewModel to do something and then report the status of that action. from what i can tell the "offical MVVM" way is to have the View subscribe to an Interaction Service in the ViewModel and then issue a command to the ViewModel. the ViewModel executes the command and then pushes a message to the Interaction Service which the View receives and then performs an action

this is ludicrous if you want an "OK" button that saves some data and pops up an error message if something doesnt work

Mr Shiny Pants posted:

You create a status label that is two way binded to your outcome. So in your GUI you have something like a status field and you save the outcome to the field its binded to in your viewmodel and the Gui will show the outcome if it is necessary.

At least, that is what I would do.

NEED MORE MILK posted:

This is a dialog though, so when I hit "OK" I want to set DialogResult = true to close the dialog if the command is successful and pop up a MessageBox if it fails

Roid666 posted:

Windows forms isn't going anywhere, but if I were learning from scratch WPF is weapon of choice now.

EssOEss posted:

What sort of app and who is the target audience in terms of users?

EssOEss posted:

WPF is the most powerful option but not very loved by Microsoft. UWP is the "modern mobile UI kit" that gets all the attention these days.

hackbunny posted:

"Not going anywhere" in the sense that they won't get any significant updates, or in the sense that they won't be dropped any soon?

quote:

I was afraid you'd say that! I'd rather go with a desktop application unless there are very, very good reasons not to. Microsoft mobile platforms are not on our radar right now and they don't look like they'll ever be

Munkeymon posted:

It's technically ~mobile-friendly~ and a requirement to use the app store IIRC.

Munkeymon posted:

You know how most of the apps that come with Windows 10 look? That's probably what they're using.

Ciaphas posted:

Is there a way in C# to require that a string parameter (or hell numeric ones too) to a function be filled via a literal rather than a variable or other expression that requires evaluation?

C# code:

var result = Foo("id1"); // ok
string id = "id1"; var result = Foo(id); // not ok

It's an awkward edge case I'm running into involving walking CSharpSyntaxTrees from user scripts.

LongSack posted:

If there is, it would be some deeply weird poo poo involving reflection, but even then I am dubious, because typeof(“foo”) and typeof(string) are almost certainly the same.

hackbunny posted:

For want of a proper Windows thread, I'll ask here: how would you write a UI for a Windows desktop application? My coworker wants to use Windows Forms but hasn't it been obsolete for a long time? Not that I know much about UI development on Windows...

hackbunny posted:

Is the single window UI a hard requirement or just convention?

uncurable mlady posted:

electron

chippy posted:

Is Electron really bad or something (or was this a serious recommendation)? I assume it was pretty good, mainly because there are some decent apps built on it. I saw an interesting blog article about creating an app that was basically a self-hosted WebAPI app using .NET Core, with an Electron UI.

Munkeymon posted:

uncurable mlady posted:

electron

Munkeymon posted:

WPF is being neglected/in maintenance mode in favor of UWP because they figured out too late that it's to hard or impossible to offload things WPF does to a mobile GPU because of the way it's structured under the hood, IIRC. WPF, like Forms, won't go away because that would break thousands of internal applications that Microsoft's primary customers depend on.

hackbunny posted:

Another question: correct me if I'm wrong, but .NET still doesn't have a standard way to specify/suggest that a return value or argument can't be null, right? There's Nullable to make value types nullable, but nothing to make reference types non-nullable? [and what's taking them so long?]

Drastic Actions posted:

WPF is not being neglected, nor is it "in maintenance mode". It's still a major, supported framework for building applications on Windows and new features are being added to it. Hell, even WinForms is getting new features in Windows 10, such as better high DPI support out of the box.

New Yorp New Yorp posted:

It's coming:
https://blogs.msdn.microsoft.com/dotnet/2017/11/15/nullable-reference-types-in-csharp/

hackbunny posted:

UWP is not for desktop apps, is it? It's for sandboxed store apps, right? That's the main thing stopping me

e: ... MFC then?


That's what I found, too. It's not very promising that it seems to be a C# thing only

beuges posted:

Non-nullable objects in C#8 is entirely a set of compiler rules - it doesn't affect the generated IL at all. So it's not a feature of .net itself, it's just the C# compiler getting cleverer/stricter.

Funking Giblet posted:

Wonder what nameof does in this scenario

beuges posted:

UWP apps can run on the desktop, they're not limited to phones only, but they're meant to be distributed via the store, not as standalone software. If your users are not likely to want to use the store, that's going to be a big factor. edit: also, UWP apps will limit you to running on Win10.

LongSack posted:

Although, now I’m curious what nameof(“string”) or nameof((object)”string”) would return ...

Night Shade posted:

CS8081, apparently.

Night Shade posted:

That's a compiler error, not an exception. nameof(thing) is replaced with a string constant by the compiler. It's got some smarts in there about taking the last identifier in a dotted path of identifiers, so nameof(System.Object.ToString) gets replaced with "ToString", but it doesn't work on literals or anything that needs to be evaluated at runtime.

It also doesn't work how you may think for generic type parameters - nameof(TKey) is always "TKey", not typeof(TKey).Name. It basically exists to give refactoring tools something they can guarantee needs to be updated instead of guessing that "MyFunction" and void MyFunction() are the same thing.

beuges posted:

UWP apps can run on the desktop, they're not limited to phones only, but they're meant to be distributed via the store, not as standalone software. If your users are not likely to want to use the store, that's going to be a big factor. edit: also, UWP apps will limit you to running on Win10.

beuges posted:

Non-nullable objects in C#8 is entirely a set of compiler rules - it doesn't affect the generated IL at all. So it's not a feature of .net itself, it's just the C# compiler getting cleverer/stricter. I guess the same rules could be built into the VB.net compiler as well, although I'm not sure why anyone would want to start a new .net project in VB in the first place.

mystes posted:

Doesn't there have to be some sort of change to the output if it's supposed to be able to detect nullable annotations in libraries?

raminasi posted:

Aren't UWP apps stuck inside a sandbox? Like they can't (for example) touch the greater filesystem?

hackbunny posted:

Another question: correct me if I'm wrong, but .NET still doesn't have a standard way to specify/suggest that a return value or argument can't be null, right? There's Nullable to make value types nullable, but nothing to make reference types non-nullable? [and what's taking them so long?]

TheBlackVegetable posted:

.NET does, it's called F#.

roflsaurus posted:

What's the best way to do non-trivial validation on domain model entities in ASP.Net MVC Core MVVM? MVC has great auto-validation for ViewModels, but not if your domain models aren't going through the model binding process

I have set up view models which can be validated from the DataAnnotations. But then with domain models I want to do some further checking - e.g.

• check if a record already exists with that unique key and show a friendly error
  
• check if an IP Address range is valid syntax
  
• if property X is set, then property Y must be set
  

At the moment I'm doing it in the controller and it doesn't feel right. It seems EF Core have washed their hands of validation entirely (doesn't even check for duplicate PKs - just throws an SQL Exception)

I can use FluentValidation or some other kind of library, but it seems this still relies on the controller performing the validation (instead of validating on DbContext.Save). This won't work if I don't trust the UI layer. Ideally i'd call DbContext.Save, which would then call a custom Validate() function on my domain object. It could then return a list of DbValidationErrors or similar which I can bubble up to a UI / API. Am I missing something?

hackbunny posted:

It's the existence of F# that made me hope there was a standard or standard-ish set of attributes I could annotate stuff with. But, no. At least, nothing language-agnostic

B-Nasty posted:

nameof is particularly useful for ArgumentNullExceptions where you don't have to worry about your function parameter names deviating from the magic strings. e.g.

code:

private void MyFunc(string fizzBuzz){
    if(fizzBuzz == null)
        throw new ArgumentNullException(nameof(fizzBuzz), "Nulls not allowed, you dummy");
}

That way, when someone changes fizzBuzz to fizzBuzzBazz, the compiler freaks out instead of that exception always being confusing. That and property change events are about the only practical uses I've had.