|
Supersonic posted:On the topic of WPF, I've been working on a larger WPF project with some other people, and one issue I've been running into is understanding Databinding. For example, consider the following view: Those things are just properties being set on the created Binding object, and you can check the documentation for each property to see what happens if it's unset. (For example, if Path is unset, it's equivalent to Path=..) You should also read the Binding declarations overview if you haven't yet.
|
# ? Jan 1, 2022 19:26 |
|
|
# ? Jun 7, 2024 09:16 |
|
This is kinda overkill but what about making a self-hosted webapp. Then you can build the frontend with HTML, grab some JS library for dashboard widgets and plug everything together with ajax.
|
# ? Jan 2, 2022 05:18 |
|
Kyte posted:This is kinda overkill but what about making a self-hosted webapp. Then you can build the frontend with HTML, grab some JS library for dashboard widgets and plug everything together with ajax. Retool does this for you more or less. It's got lots of rough edges, but less than anything DIY will. Seriously just use Retool or maybe airtable.
|
# ? Jan 2, 2022 12:23 |
|
insta posted:The actual use-case is customers defining 'dashboards' for serial-connected devices. The devices will have different parameters that can be either read or written, and sometimes the 'write' needs to be an expression from the 'read'. The devices are not all the same, and each customer has a different use-case for the parameters they want to read or write. Piling on here too. By chance, did they themselves mention "dashboard?" If so, I would call them out on that. Those are presentation layers for viewing data and all the interaction should be in messing with that view. There's a bunch of poo poo for that and you won't hear and angel sing for using any of them. However, as soon as interaction like those writes come into play, it is indeed another person's attempt to avoid programming that will eventually require programming anyways.
|
# ? Jan 3, 2022 02:44 |
|
Am I missing something, or does GetFromJsonAsync preclude accessing response headers? I'm consuming an API for which each method's rate-limit info (requests per interval allowed, remaining requests in this interval, and when this interval ends) is communicated via x-headers in the response. GetFromJsonAsync will throw an HttpRequestException if the request was unsuccessful, and it can tell me that the status code was 429 TooManyRequests, but the exception doesn't seem to include any response header data, so I can't say how long to wait before trying again. So far, it seems like I'll have to switch to GetAsync plus ReadFromJsonAsync, but I'm open to being wrong about that!
|
# ? Jan 6, 2022 03:15 |
|
The new extension methods are for fairly simple scenarios. They're just calling HttpResponseMessage.EnsureSuccessStatusCode(), which only gives you the status code, so you're on the right track. Mind, you can still use GetFromJsonAsync() and have retries based on response headers if you feel up to creating a custom retry policy using Polly. No Pants fucked around with this message at 04:48 on Jan 6, 2022 |
# ? Jan 6, 2022 04:34 |
|
What gets me is that PostAsJsonAsync and PutAsJsonAsync both return Task<HttpResponseMessage>, so in those cases I can get what I need from HttpResponseMessage.Headers.GetValues. It's just GetFromJsonAsync that seems to be the odd one out, returning Task<Object> instead. At a glance, Polly seems like overkill for what I'm doing, but also like something I should probably get familiar with, so thanks for putting it back on my radar!
|
# ? Jan 6, 2022 05:30 |
|
Toast Museum posted:What gets me is that PostAsJsonAsync and PutAsJsonAsync both return Task<HttpResponseMessage>, so in those cases I can get what I need from HttpResponseMessage.Headers.GetValues. It's just GetFromJsonAsync that seems to be the odd one out, returning Task<Object> instead. I can sort of see the logic of it. With Get you're always going to be interested in the response body, so it's convenient for the response to simply be the deserialized object. With Put and Post you often only care about the status, so it makes less sense to automatically deserialize the response. The "AsJson" in the Put and Post refers to the input rather than the output. But yeah, if you need to inspect the headers of a Get request you'll need to use GetAsync directly.
|
# ? Jan 6, 2022 10:48 |
|
LOOK I AM A TURTLE posted:I can sort of see the logic of it. With Get you're always going to be interested in the response body, so it's convenient for the response to simply be the deserialized object. With Put and Post you often only care about the status, so it makes less sense to automatically deserialize the response. The "AsJson" in the Put and Post refers to the input rather than the output. Nah, that's reasonable, even if it's proving inconvenient at the moment. I certainly didn't mind the reduced boilerplate until now. It would be nice if the headers wound up in HttpRequestException.Data or something, though.
|
# ? Jan 6, 2022 15:41 |
|
I don't really like the HttpClient to be honest, and I like that I can just create a HttpWebRequest from scratch using the "obsolete" APIs. Is there any reason I need to switch? I mean, System.Net is pretty bulletproof by now right?
|
# ? Jan 7, 2022 10:09 |
|
Mr Shiny Pants posted:I don't really like the HttpClient to be honest, and I like that I can just create a HttpWebRequest from scratch using the "obsolete" APIs. If you want to build your own wrapper around it, to handle all connection pooling/error and timeout handling/disposal, there's no reason to switch. If you want those things, HttpClient is the only reliable built-in way to get them. Additionally, if you're working with modern ASP.NET Core then HttpClient itself is well integrated so you can more easily grab instances of it as needed (tied to scope, etc).
|
# ? Jan 7, 2022 11:06 |
|
Red Mike posted:If you want to build your own wrapper around it, to handle all connection pooling/error and timeout handling/disposal, there's no reason to switch. If you want those things, HttpClient is the only reliable built-in way to get them. I get that, and some things it does well (Forms and the like) but for just getting a reply from an endpoint I really like just being able to create an async method from scratch and know where all the stuff is getting used. I really like being able to do: code:
|
# ? Jan 7, 2022 11:11 |
|
Mr Shiny Pants posted:I get that, and some things it does well (Forms and the like) but for just getting a reply from an endpoint I really like just being able to create an async method from scratch and know where all the stuff is getting used. So is there a difference between that and this (C# obviously): code:
e: Also to be clear, I think some of the choices in HttpClient are pretty daft. The timeout handling especially is finnicky and can catch you by surprise in certain situations (hitting the same URL/path with different data for different operations, and some operations being expected to sometimes time out while others don't - this can cause those others to also act as if they timed out if they were pending while the first one times out - the workaround is to always pass in a CancellationToken as appropriate instead of letting it create one against the URL/path/handler) But I still prefer it to the raw request classes whenever I actually need to do HTTP because it's a low enough level construct that I just care about the HTTP request happening, and any fixes I want to this logic need to apply to all outgoing HTTP requests anyway. Basically, my job is to solve problems, not to write perfect code. Red Mike fucked around with this message at 11:30 on Jan 7, 2022 |
# ? Jan 7, 2022 11:26 |
|
I have a situation where I'm creating two HashSets with contents that equal each other, although the contents themselves are unique instance between each other (so they're not literally the same object, but Equals() is implemented). When try to use Equals to check both HashSets, I get false, but SetEquals() is true. Should I normally be using SetEquals here? Edit: In this particular case it's for asserting in my unit testing that the set I produce in my test equals a reference for what the set should contain.
|
# ? Jan 21, 2022 09:24 |
|
According to the docs, HashSet.Equals compares the object identities (it just inherits from Object). SetEquals compares the contents. You clearly want the latter. (Element equality is checked using IEqualityComparer btw)
|
# ? Jan 21, 2022 09:30 |
|
Some people from my work have a boner for MS Power Apps, but I hate working with them, and they always become a pain to maintain beyond a PoC stage. Are there any good alternatives in C# frameworks that can match the PoC speed, but also be robust, where I can still control the code?
|
# ? Jan 21, 2022 10:37 |
|
Any ASP.NET experts here? Particularly with the web.config and IIS10? We have a custom error page to handle any errors, and we need that initial form data to go along for the ride. This works when deployed to our old Server 2012 instance on AWS, and run on localhost via Visual Studio and IISExpress on a Server 2019 machine: code:
I feel like I'm missing some setting in IIS10, but Googling isn't bringing anything up.
|
# ? Jan 21, 2022 15:29 |
|
Boz0r posted:Some people from my work have a boner for MS Power Apps, but I hate working with them, and they always become a pain to maintain beyond a PoC stage. Are there any good alternatives in C# frameworks that can match the PoC speed, but also be robust, where I can still control the code? Ahh the never ending cycle. Developers are expensive! Let's use a tool to let business users develop solutions without developers! This thing we built is too complex and hard to maintain! We need developers! Everyone claims to have learned their lesson and to just let developers write software. GOTO START
|
# ? Jan 21, 2022 19:04 |
Writing the code is the least important part of writing code
|
|
# ? Jan 21, 2022 19:13 |
|
Boz0r posted:Some people from my work have a boner for MS Power Apps, but I hate working with them, and they always become a pain to maintain beyond a PoC stage. Are there any good alternatives in C# frameworks that can match the PoC speed, but also be robust, where I can still control the code? Isn't that what the azure functions integration stuff is for?
|
# ? Jan 22, 2022 08:12 |
|
Can anyone help me write this LINQ statement or tell me some keywords to google? I have a List<Video> and each Video object has its own List<Tag>. I want to select all the Tags that the list of Videos has in common. So like: code:
|
# ? Jan 22, 2022 15:27 |
|
You're looking for the intersection of all the sets of tags. You could do something like: code:
|
# ? Jan 22, 2022 15:52 |
|
fuf posted:Can anyone help me write this LINQ statement or tell me some keywords to google? Probably not the best solution code:
|
# ? Jan 22, 2022 16:00 |
|
Jabor posted:You're looking for the intersection of all the sets of tags.
|
# ? Jan 22, 2022 16:05 |
|
How about this?code:
Chrungka fucked around with this message at 16:17 on Jan 22, 2022 |
# ? Jan 22, 2022 16:15 |
|
Thanks a lot guys, much appreciatedJabor posted:You're looking for the intersection of all the sets of tags. This works fine, but I can't claim to understand exactly what's going on. I need to do a LINQ course or something.
|
# ? Jan 22, 2022 17:51 |
|
fuf posted:Thanks a lot guys, much appreciated The only Linq in there is the Skip(1) which you probably don't need a whole course for, but understanding the HashSet data structure and set operations more generally is good.
|
# ? Jan 22, 2022 18:01 |
|
fuf posted:Thanks a lot guys, much appreciated The first line is copying the tags of the first video. (This will cause an exception if the list of videos is empty.) The loop is over the set of videos. At each loop iteration, the set of tags is updated to be the intersection between the current set, and the tags of the current video. Once all videos have been looped through, you are left with only the tags that are found on every video in the list. The .Skip(1) skips over the first video. It doesn't make a difference to the final result, it just isn't necessary to perform that intersection operation, because by definition it's going to make no difference (the set of tags has been initialised to the tags of the first video already; intersection of a set with itself yields the same set again).
|
# ? Jan 22, 2022 18:11 |
|
Monthly reminder that if you are ever doing a . Contains() operation on a collection, you probably want a HashSet unless you know for sure you want a List. I see this way too often and it's a huge performance drain. *Especially* if you are doing something as a "if not Contains, do an operation and add it to the list and loop" thing.
|
# ? Jan 22, 2022 18:59 |
|
Kyte posted:According to the docs, HashSet.Equals compares the object identities (it just inherits from Object). SetEquals compares the contents. You clearly want the latter. I had seen your response yesterday but I had to double check something today. I also have a similar with where I use a List<> and I thought Equals() was comparing contents there. But I checked it today and bam, I am manually comparing contents. So that is what I get for 2AM coding.
|
# ? Jan 22, 2022 19:40 |
|
Copy both lists to HashSets and subtract them from each other. If there's any elements left, they don't match. This will be way faster than whatever you're doing.
|
# ? Jan 22, 2022 19:42 |
|
insta posted:Copy both lists to HashSets and subtract them from each other. If there's any elements left, they don't match. This will be way faster than whatever you're doing. Order matters for the list comparison. I just thought for some reason that List.Equals would check contents (which it doesn't and I wasn't even using) so HashSet.Equals should also check contents. It was a real brain fart all around.
|
# ? Jan 22, 2022 20:32 |
|
Rocko Bonaparte posted:Order matters for the list comparison.
|
# ? Jan 22, 2022 21:12 |
|
Rocko Bonaparte posted:I had seen your response yesterday but I had to double check something today. I also have a similar with where I use a List<> and I thought Equals() was comparing contents there. But I checked it today and bam, I am manually comparing contents. So that is what I get for 2AM coding. if this is still for unit testing, testing frameworks usually have an equality assertion method that compares the contents of collections.
|
# ? Jan 22, 2022 21:20 |
|
SirViver posted:For that you can just use the .SequenceEqual() LINQ extension. A small optimization for that would be to additionally compare the list counts before comparing the sequence - the extension method doesn't check for that kind of shortcut IIRC. SequenceEqual checks the lengths, at least in recent .NETs. https://github.com/dotnet/runtime/b...nceEqual.cs#L32
|
# ? Jan 22, 2022 22:32 |
|
Rocko Bonaparte posted:Order matters for the list comparison. I just thought for some reason that List.Equals would check contents (which it doesn't and I wasn't even using) so HashSet.Equals should also check contents. It was a real brain fart all around. If order matters, that should be part of the object in the HashSet, and the equality and GetHashCode methods should be aware of it
|
# ? Jan 22, 2022 23:42 |
|
Guys, I brought up list because I had incorrectly thought it deep compared and was surprised HashSet.Equals did not. I did not intend to literally compare a List and a HashSet. I was just incorrectly referencing behavior from other collections in the .NET framework.
|
# ? Jan 23, 2022 18:12 |
|
Question about using DI in a desktop application. My Ledger application was originally written using the Locator pattern. I've since been informed that some (many?) people consider the Locator to be an anti-pattern because it obfuscates the dependencies (i.e., you can't just look at the constructor and see the dependencies). Point taken. So I'm rewriting the application into .NET 6 / C# 10 using dependency injection (not because of the Locator, there are other reasons to rewrite and I'm just taking advantage of them to remove the Locator as well). I'm just getting started on the WPF client, and I've got this so far: C# code:
However, once the app is complete, there will be an additional 20 or so view models, which are all used with windows called from the MainViewModel. This means that - at the end - to instantiate the MainViewModel, I'll also have to instantiate all of the other view models with their respective dependencies, essentially instantiating the entire application. This is not good. My data access classes are designed to be transient. So I'm thinking, to work around this, that I'll use a factory class to instantiate the view models, something like this: C# code:
So, is this a terrible idea? Is there a better way? TIA
|
# ? Jan 23, 2022 19:12 |
|
LongSack posted:This means that - at the end - to instantiate the MainViewModel, I'll also have to instantiate all of the other view models with their respective dependencies, essentially instantiating the entire application. This is not good. My data access classes are designed to be transient. Instead of depending directly on those transient view models, you could depend on a view model factory (or one per VM depending on if the dependencies have much overlap). There are a few different ways to set this up depending on exact requirements and preferences, there are a bunch explained here: https://stackoverflow.com/a/2280289 The Microsoft DI framework has explicit support for scoped dependencies but idk if it's easy to use outside of asp.net
|
# ? Jan 23, 2022 20:39 |
|
|
# ? Jun 7, 2024 09:16 |
|
In particular, your ViewModelFactory should either have the ViewModel's dependencies as its own dependencies, and then new one up as required (some say this is bad), or take in a function that creates ViewModel instances that is defined at app tree construction time (possibly using service location at that point)
|
# ? Jan 23, 2022 20:51 |