|
*edit: Stupid question, removed.
A Tartan Tory fucked around with this message at 21:31 on Aug 26, 2014 |
# ? Aug 26, 2014 21:17 |
|
|
# ? May 19, 2024 13:11 |
|
Syntactically valid code would be a good start. It looks like you have a class copied and pasted into the middle of a method.
|
# ? Aug 26, 2014 21:29 |
|
Ithaqua posted:Syntactically valid code would be a good start. It looks like you have a class copied and pasted into the middle of a method. Welp, I think my brain needs a rest at this point, because I didn't even see that. Ignore the above stuff, I'll have a look when I'm at least marginally refreshed enough to see basic poo poo again.
|
# ? Aug 26, 2014 21:31 |
|
Your code is getting pretty spaghetti-like imo, so instead of trying to parse it I'll just post what I did. I will again recommend you watch the video. It's 20 minutes well spent. Model C# code:
C# code:
XML code:
Edit: missed a comment. Knyteguy fucked around with this message at 23:01 on Aug 26, 2014 |
# ? Aug 26, 2014 21:33 |
|
A Tartan Tory posted:Welp, I think my brain needs a rest at this point, because I didn't even see that. You might want to throw your code up on to github or something as well, and then link to specific files instead of just pasting bits of it here. Unless this is something you can't make public, it's easier to process all together instead of just getting parts. EDIT: Oh yeah, this might be a good place for this. VLC needs more people for the VLC WinRT port. Right now there is really only one person working full time on it. The codebase, while not as bad as it was a few months ago when I first saw it, still needs to be refactored quite a bit. I've been working on it off and on for a few months now. They are getting ready to release an updated 8.1 app, and it actually works pretty well (considering how poor the first version was, that's not saying much, but still ). If any of you are up for a challenge, and have worked on Windows Phone/Windows 8 apps before, it's a good way to get involved in a huge open source project. Drastic Actions fucked around with this message at 21:57 on Aug 26, 2014 |
# ? Aug 26, 2014 21:40 |
|
A Tartan Tory posted:Welp, I think my brain needs a rest at this point, because I didn't even see that. Other posters have provided a lot of great information on the technicalities, so I'll make a comment on a tangential issue. You seem a little down on yourself, based on a couple of your posts. Quit it. You're learning something new, and despite what some people have said, it's not really simple. It's not difficult once you figure out how everything fits together, but actually getting to that point takes some work. If you're not familiar with it, especially its declarative nature, it's a fairly alien mindset that you have to train yourself to acquire. So don't feel bad that you aren't getting it right away, is what I'm saying. What I would suggest is that once you've gone through whatever videos and tutorials you're going to go through, go make something simple on your own. Put your current project on hold and make an MVVM program that has a textbox and a button that adds 5 to the value in the textbox or something. Make it work perfectly using MVVM and only MVVM. If you can't do it, go back and watch the videos/do the tutorials again. Repeat until you have the blinding epiphany.
|
# ? Aug 26, 2014 23:17 |
|
Che Delilas posted:Other posters have provided a lot of great information on the technicalities, so I'll make a comment on a tangential issue. Very true. WPF threw me for a loop for quite a while (and it still does occasionally, the binding syntax can be downright awful).
|
# ? Aug 26, 2014 23:26 |
|
Scuzzywuffit posted:// Window stuff As it turns out, the reason my program had a window that wasn't closing properly was because I left a constructor call in my code from before I refactored it. So I created two windows, and never closed one In other words, I am literally the dumbest person on the entire planet.
|
# ? Aug 27, 2014 00:13 |
|
Anyone have any recommendations for WPF charting/plot/graphing controls that are free (and preferably open source)? I've tried Oxyplot already; while it basically works, trying to make my lineplot zoom to the actual data automatically when it changes is making me tear my hair out. (I feel like parts weren't made with MVVM in mind, 'cos I can do it fine if I cheat and access my view from the view model.) Ciaphas fucked around with this message at 00:33 on Aug 27, 2014 |
# ? Aug 27, 2014 00:30 |
|
Che Delilas posted:Other posters have provided a lot of great information on the technicalities, so I'll make a comment on a tangential issue. Honestly, I'm on a massive downer because of this mostly because even after the better part of a week of dedicated study on it, including multiple examples from everyone here and youtube videos etc. I just straight up don't get it. I don't get it to the extent where I don't even know where to start doing the basic program you say to try and I really don't understand why I can't either. Everything I make at the moment regarding it seems like a massive jumbled up mess that makes no sense, when it made perfect sense when I did it with the console. I feel like a complete helpless idiot doing this stuff and I'm struggling to think of how to get over this hurdle because nothing I do actually seems to work and it is incredibly frustrating. A Tartan Tory fucked around with this message at 01:51 on Aug 27, 2014 |
# ? Aug 27, 2014 01:48 |
|
A Tartan Tory posted:Honestly, I'm on a massive downer because of this mostly because even after the better part of a week of dedicated study on it, including multiple examples from everyone here and youtube videos etc. I just straight up don't get it. I think following Drastic Actions's advice would be a good idea at this point - get yourself a github or bitbucket and make your whole project available for people to look at. There are a bunch of things that you have to do to get MVVM to work right, and chances are you're just missing a piece or two. And as I mentioned before, none of the pieces are really very intuitive. I'm sure we'll be able to at the very least track down what you're missing. Che Delilas fucked around with this message at 02:42 on Aug 27, 2014 |
# ? Aug 27, 2014 02:38 |
|
Scuzzywuffit posted:As it turns out, the reason my program had a window that wasn't closing properly was because I left a constructor call in my code from before I refactored it. So I created two windows, and never closed one Welcome to a very select club, my friend. Let me introduce you to your fellow members: literally everyone who has done object-oriented programming.
|
# ? Aug 27, 2014 02:41 |
|
A Tartan Tory posted:Honestly, I'm on a massive downer because of this mostly because even after the better part of a week of dedicated study on it, including multiple examples from everyone here and youtube videos etc. I just straight up don't get it. Nthing everyone else here: WPF/MVVM is not easy. It took all of us some time to understand it. Once you hit that 'aha' moment then you realize it turns into something spectacular and never want to go back to winforms. I helped someone convert their example program to proper MVVM in another thread. Granted the dealer hitting/staying logic doesn't work, but it's a simple example of INotifyPropertyChanged, RelayCommand, and datacontext implementations.
|
# ? Aug 27, 2014 02:55 |
|
Che Delilas posted:I think following Drastic Actions's advice would be a good idea at this point - get yourself a github or bitbucket and make your whole project available for people to look at. There are a bunch of things that you have to do to get MVVM to work right, and chances are you're just missing a piece or two. And as I mentioned before, none of the pieces are really very intuitive. I've basically deleted everything I've made at this point, multiple times, when/if it gets to that stage again I'll box it all up I guess. candy for breakfast posted:Nthing everyone else here: WPF/MVVM is not easy. It took all of us some time to understand it. Once you hit that 'aha' moment then you realize it turns into something spectacular and never want to go back to winforms. Would starting with winforms help me understand WPF?
|
# ? Aug 27, 2014 03:14 |
|
A Tartan Tory posted:I've basically deleted everything I've made at this point, multiple times, when/if it gets to that stage again I'll box it all up I guess. Avoid Winforms. Unless you have a reason to use it, don't. Not at this point. I would say it would not help much at all from a WPF angle, because they are different. And you don't have to have a fully working project to throw it on Github, or at the very least put it under local source control. Just put what you have and do commits when you make changes. That way you can mark what you're doing and go back if you need to.
|
# ? Aug 27, 2014 03:18 |
|
Nope! All the good poo poo that you can do with WPF can't be done with winforms.
|
# ? Aug 27, 2014 03:18 |
|
A Tartan Tory posted:Honestly, I'm on a massive downer because of this mostly because even after the better part of a week of dedicated study on it, including multiple examples from everyone here and youtube videos etc. I just straight up don't get it. Here dude I whipped up an example WPF application for you to screw around with. Organization/convention may not be perfect but it shows the MVVM pattern, and it is an example application that you can try to recreate yourself to help get the gist of it. https://github.com/Noppadet/ExampleXamlApplication The UI is ugly as hell but it works. Anyway hope that can help some. Knyteguy fucked around with this message at 16:05 on Aug 27, 2014 |
# ? Aug 27, 2014 04:12 |
|
A Tartan Tory posted:Honestly, I'm on a massive downer because of this mostly because even after the better part of a week of dedicated study on it, including multiple examples from everyone here and youtube videos etc. I just straight up don't get it. I find it easiest to start with the view first, as it's static and visual both of which make it easier to wrap your head around what you want and what needs to be done. Program your view and keep it super basic, don't worry about specific bindings and gluing a view model together, think about it at that high user level. THEN you can think about what you need to expose on a view model to get your view to work. THEN you can add your business logic. This is kind of backwards from the real world and maybe even "ideal" scenario but when I'm first getting started on a project or helps me get a coherent first step. Also by no means is the view side of things easy, on the contrary it's a rabbit hole of complexity you'll never escape; but if you just want to throw some basic buttons and fields in a window it is fairly simple. Don't get to wrapped up in best practices and trying add more frameworks to "help" you either, get the basics down first then start worrying over having code in the code behind etc.
|
# ? Aug 27, 2014 04:29 |
|
Since we're talking about MVVM and WPF and how the rules work, let me ask a question about breaking said rules. I don't have my code from work, as usual, but is something like the stuff bordered by slashes a total faux pas? A loose coupling from the view-model to the view? (The specific actual code involves OxyPlot being, unless I really missed something, a bit dumb about trying to automatically pan and zoom to updated data for its plots.) C# code:
Ciaphas fucked around with this message at 06:17 on Aug 27, 2014 |
# ? Aug 27, 2014 06:11 |
|
Why not just have the viewmodel set a property RequiresUpdate and have a DataTrigger bound to that?
|
# ? Aug 27, 2014 12:39 |
|
i hit another pair of The WPF team has recently reviewed this issue and will not be addressing this issue as at this time the team is focusing on the bugs impacting the highest number of WPF developers. at work today
|
# ? Aug 27, 2014 14:04 |
|
Ciaphas posted:Since we're talking about MVVM and WPF and how the rules work, let me ask a question about breaking said rules. My view is developers get to zealous about that (bolded); you can't avoid the code-behind (writing controls, anything to do with dependency objects etc). The primary motivation is to make sure you're not mixing view-model concerns into your view and vica-versa I think. That's the typical pattern for showing notifications etc; though the 'ideal' decoupled way for that specific example would be to use an event bus, which most of the MVVM frameworks have implemented in some form or another. I personally don't view anything wrong with that if it's not all over the place or you're in a small project.
|
# ? Aug 27, 2014 15:25 |
|
Ciaphas posted:Since we're talking about MVVM and WPF and how the rules work, let me ask a question about breaking said rules. This is exactly how I deal with showing a MessageBox. By the way, it should be MessageBox.Show(this, "hello"), and this is the Window. (If you don't tell windows who their owners are, you're opening yourself up to weird UI window-ordering bugs.) If you take it a little further, instead of Action you can use Func<bool> for OkCancel type confirmations. Once that's in place, you can test your VM by hooking up a function that returns true (or false) as if the user clicked OK (or Cancel) on the confirmation dialog.
|
# ? Aug 27, 2014 15:43 |
|
Cool, thanks for the input. I'm still trying to learn WPF and MVVM, so knowing when and why I can/should break the rules is a big help.Gul Banana posted:Why not just have the viewmodel set a property RequiresUpdate and have a DataTrigger bound to that? I forgot about DataTriggers . I'd still have to have code in the CodeBehind to call MyOxyPlot.ResetAllAxes() or whatever it is, but at least there'd be less plumbing. I'll try that at work today, thanks!
|
# ? Aug 27, 2014 16:16 |
|
Knyteguy posted:Here dude I whipped up an example WPF application for you to screw around with. Organization/convention may not be perfect but it shows the MVVM pattern, and it is an example application that you can try to recreate yourself to help get the gist of it. Thanks for this, after a bit of calming rest and relaxation, I was able to use this to build something basic that actually worked. Progress!
|
# ? Aug 27, 2014 22:35 |
|
A Tartan Tory posted:Thanks for this, after a bit of calming rest and relaxation, I was able to use this to build something basic that actually worked. Oh man, forgot that piece of advice. Stepping away from the problem for a length of time does wonders. Can't tell you how many times I've beat my head against the wall all day at the office, only to have a blinding epiphany 15 minutes into my commute home.
|
# ? Aug 27, 2014 22:55 |
|
Drastic Actions posted:EDIT: Oh yeah, this might be a good place for this. I looked through the recent commits and read some of the code, but I was trying to find some low hanging fruit to go after that would actually be warranted. Is there a list of goals or bugs specifically for the WinRT version? I briefly browsed their bug tracker but the different milestones didn't seem terribly relevant.
|
# ? Aug 28, 2014 01:58 |
|
Bognar posted:I looked through the recent commits and read some of the code, but I was trying to find some low hanging fruit to go after that would actually be warranted. Is there a list of goals or bugs specifically for the WinRT version? I briefly browsed their bug tracker but the different milestones didn't seem terribly relevant. Yeah, they have one, but don't really use it. Really, the best way to fix bugs is to get pull the branch down and run it. Because use it for a little bit, and you'll find a bug. But at this point for a release it's somewhat minor. The easiest thing to fix right now is getting rid of hard coded strings and putting them into the resources files. They originally did not have any and everything was hard coded into English in the XAML. I built the English and Japanese Resw files and started populating them and getting rid of the hardcodes, but when I left and came back, they kept putting them in raw. You don't have to translate them of course, but putting the strings into the English resw file would be grand. It'll also show you more of their code, and some of the... um... poor decisions they made along the way.
|
# ? Aug 28, 2014 02:12 |
|
Drastic Actions posted:Avoid Winforms. Unless you have a reason to use it, don't. Not at this point. I would say it would not help much at all from a WPF angle, because they are different. Winforms isn't that bad if you have some discipline but you end up having to work with other people who put all the calculations in the freaking code-behind.
|
# ? Aug 28, 2014 03:07 |
|
This is ObservableCollection<T>: Why is PropertyChanged protected, instead of public like CollectionChanged? What if I want to be notified when the Count property changes? As I currently want to, since I'm implementing ISupportIncrementalLoading. These questions are mostly rhetorical, I'm just once again irritated by OC<T>.
|
# ? Aug 28, 2014 03:55 |
|
ObservableCollection has lots of warts. In case you wanted a real answer, you can just convert the ObservableCollection into an INotifyPropertyChanged.
|
# ? Aug 28, 2014 04:05 |
|
Factor Mystic posted:This is ObservableCollection<T>: Of all the reasons to hate OC<T> that seems like the silliest.
|
# ? Aug 28, 2014 05:35 |
|
RICHUNCLEPENNYBAGS posted:Winforms isn't that bad if you have some discipline but you end up having to work with other people who put all the calculations in the freaking code-behind. You can say the same thing about ASP.NET Webforms or WCF but that don't mean you should start projects built around them.
|
# ? Aug 28, 2014 12:57 |
|
wwb posted:You can say the same thing about ASP.NET Webforms or WCF but that don't mean you should start projects built around them. Exactly. If you're stuck working on a project that's using them already, that's one thing. Choosing to learn them first when you don't know either? Yeah, I would say don't bother.
|
# ? Aug 28, 2014 13:04 |
|
A visual studio question. I'm used to being able to edit code in c++ projects while the program is running in a debugger, and when I'm at a suitable point I ctrl-alt-break to pause, and F5 to spark an edit-and-continue rebuild. In .NET, I haven't been able to figure out how to do this. Open source files for running projects are decorated with a little lock icon, and attempts to edit them are met withEdit and Continue posted:Changes are not allowed while code is running or if the option 'Break all processes when one process breaks' is disabled. The option can be enabled in Tools, Options, Debugging. Any way to get around this?
|
# ? Aug 28, 2014 13:41 |
|
Newf posted:A visual studio question. I'm used to being able to edit code in c++ projects while the program is running in a debugger, and when I'm at a suitable point I ctrl-alt-break to pause, and F5 to spark an edit-and-continue rebuild. In .NET, I haven't been able to figure out how to do this. Open source files for running projects are decorated with a little lock icon, and attempts to edit them are met with Are you trying to edit a 64 bit application in VS2012 or earlier? Edit and continue for 64 bit wasn't added until VS2013.
|
# ? Aug 28, 2014 13:57 |
|
It's VS 2010, but I'm debugging in x86 and I'm able to edit and continue if I break the running process - it just won't let me do any typing (editing) while the process is running.
|
# ? Aug 28, 2014 14:10 |
|
Newf posted:It's VS 2010, but I'm debugging in x86 and I'm able to edit and continue if I break the running process - it just won't let me do any typing (editing) while the process is running. This would break source mapping if you e.g. deleted a method with a breakpoint in it. I don't think there's a workaround-it's very annoying though
|
# ? Aug 28, 2014 14:15 |
|
Malcolm XML posted:This would break source mapping if you e.g. deleted a method with a breakpoint in it. I get that, and I get it as a reason to disallow it, but when doing it in C++ my breakpoints just change from solid red dots to little hollow dots and life goes on until the next build. One totally queer thing that I've just found is that if I edit a file OUTSIDE of VS, it asks if I'd like it reloaded, and then the 'locks' disappear from every file other than the one that I edited / reloaded. I'm then able to edit all of these in the way I wanted, complete with the edit and continue specific compiler warnings (can't alter types, etc).
|
# ? Aug 28, 2014 14:24 |
|
|
# ? May 19, 2024 13:11 |
|
Mr. Crow posted:Of all the reasons to hate OC<T> that seems like the silliest. It's the inconsistency that's depressing. I was giving my example case to preemptively head off "but why would you ever want that" questions I sometimes get from Microsoft people when I try to build things with their broken APIs.
|
# ? Aug 28, 2014 14:54 |