What are you supposed to do in InternalRefresh when you subclassing TDataset in Delphi?
Fetch the data from the database again. The public interface to this is TDataSet.Refresh.
Note that TQuery's override of this just throws an exception. There's not a strict requirement to do anything useful here, if you don't care about supporting Refresh.
Related
Does anybody knows why BlockData class doesn't directly implement IContent?
I know that during BlockData is being retrieve from database, proxy created by Castle implements IContent.
If StackOverflow isn't suitable place for this kind of a question, please move it.
Johan Björnfot at EPiServer explains some of the details in this post.
Excerpt:
"In previous versions of CMS was pages (PageData) the only content type that the content repository (traditionally DataFactory) handled. In CMS7 this has changed so now content repository (IContentRepository) handles IContent instances. This means that the requirement for a .NET type to be possible to save/load from content repository is that it implements the interface EPiServer.Core.IContent.
There are some implementations of IContent built into CMS like PageData and ContentFolder (used to group shared block instances) and it is also possible to register custom IContent implementations.If you look at BlockData though you will notice that it doesn’t implement IContent, how is then shared block instances handled?
The answer is that during runtime when a shared block instance is created (e.g. through a call to IContentRepository.GetDefault where T is a type inheriting from BlockData) the CMS will create a new .NET type inheriting T using a technic called mixin where the new generated subclass will implement some extra interfaces (including IContent)."
BlockData does implement IContent as it is intended to work both when added to another content item such as a PageData instance (a.k.a. Local Block), and as a standalone instance (a.k.a.Shared Block). In latter case the interface is added by using a mix-in though Castle Windsor so that it can be referenced.
The decision for this construct was based on wanting to be able to use the same rendering templates regardless if a block is local or shared. Therefor the choice stood between having a large number of empty properties on local blocks or the current solution using mixins. Both options were tested and mixins was selected as the preferred solution even though it's not a perfect one.
BlockData "does implement IContent", just do:
var myContent = (IContent)myBlock;
But, if you're by any chance handling a Block which itself is a property (not a ContentReference), that cast will throw an exception.
This will be true for 100% of all cases (... using Math.Round).
I have a little base view model that I use in order to override RaisePropertyChanged and RaisePropertyChanging, so I can raise the notifications without passing the name of the properties (and get it automagically).
This is how it's implemented:
public class MyBase_ViewModel : ViewModelBase
{
[NotifyPropertyChangedInvocator]
protected override void RaisePropertyChanged([CallerMemberName]string property = "")
{
base.RaisePropertyChanged(property);
}
[NotifyPropertyChangedInvocator]
protected override void RaisePropertyChanging([CallerMemberName]string property = "")
{
base.RaisePropertyChanging(property);
}
}
I've just upgraded from MvvmLight 4.something to 5.0.2, and one of the issues I experience is that it complains about : There is no suitable method for override for .
RaisePropertyChanging.
Any suggestions / ideas?
Seems like RaisePropertyChanging was removed from MVVM 5. Here's a quote from the Laurent (the author):
I had to remove PropertyChanging support because the PCL framework doesn't support this event. I am trying to see if I have a good alternative for future versions.
If you happen to run into this, you can just remove the overriding method, and it should work. Seems like nothing big will happen.
On a different note, the RaisePropertyChanging seems to be used if you're trying to do something with the value before it goes away, and I actually never used it. If you need it, you can go to this thread, where the author suggested he can provide a workaround if needed: original thread on mvvm codeplex.
I am using CompositionInitializer.SatisfyImports(this) from Glen Block with a WPF application using Prism 4.1 and Prism's MEFExtensions.
I have used this many times before and not had a problem, but every once in a while when I call SatisfyImports(this) and get the following error:
A first chance exception of type
'System.Resources.MissingManifestResourceException' occurred in
mscorlib.dll
Additional information: Could not find any resources appropriate for the specified culture or the neutral culture. Make sure
"System.ComponentModel.Composition.Initialization.Strings.resources"
was correctly embedded or linked into assembly
"Microsoft.ComponentModel.Composition.Initialization.Desktop" at
compile time, or that all the satellite assemblies required are
loadable and fully signed.
If there is a handler for this exception, the program may be safely continued.
Anyone know why I'm getting this error and how to fix it?
The CompositionInitializer approach doesn't work with WPF in some cases, as evidenced by the MissingManifestResourceException above- basically, I think this is saying that one of the imports is failing due to some resource problem of the imported DLL... which you may or may not have any control over.
The better approach (I think) is to use the MEF ExportFactory to instantiate objects for WPF applications rather than the CompositionInitializer:
[Export]
public class OrderController {
[Import]
public ExportFactory<OrderViewModel> OrderVMFactory {get;set;}
public OrderViewModel CreateOrder() {
return OrderVMFactory.CreateExport().Value;
}
}
Worked for me anyways.
I do have some questions about memory management and the export factory, but that's another post :)
I've been looking into the feasability of using Reactive UI in production code. Some of the features are really appealing, but I have concerns about taking a dependency on this library. These include:
Whacky naming and conventions. For example, protected members starting with lower case, and the RaiseAndSetIfChanged method depends on your private member beginning with an underscore. I understand Paul Betts (ReactiveUI author) has a Ruby background, so I guess that's where the odd naming stems from. However, this will cause a real issue for me, since standard naming (as per Stylecop) is enforced throughout my project. Even if it wasn't enforced, I'd be concerned by the resultant inconsistency in naming that this will cause.
Lack of documentation/samples. There is some documentation and a lonely sample. However, the documentation is just a series of (old) blog posts and the sample is based on V2 of the library (it's now on V4).
Odd design, in parts. For example, logging is abstracted so as not to take a dependency on a specific logging framework. Fair enough. However, since I use log4net (and not NLog) I will need my own adapter. I think that will require me to implement IRxUIFullLogger, which has a metric crapload of methods in it (well over 50). I would have thought a far better approach would be to define a very simple interface and then provide extension methods within ReactiveUI to facilitate all the requisite overloads. In addition, there's this weird IWantsToRegisterStuff interface that the NLog assembly depends on, that I won't be able to depend on (because it's an internal interface). I'm hoping I don't need that...
Anyway, my concern here is the overall design of the library. Has anyone been bitten by this?
I'm already using MVVM Light extensively. I know Paul did a blog post where he explains you can technically use both, but my concern is more around maintainability. I suspect it would be horribly confusing having both intermingled in one's code base.
Does anyone have hands-on experience with using Reactive UI in production? If so, are you able to allay or address any of my above concerns?
Let's go through your concerns piece by piece:
#1. "Whacky naming and conventions."
Now that ReactiveUI 4.1+ has CallerMemberName, you don't have to use the conventions at all (and even then, you can override them via RxApp.GetFieldNameForPropertyFunc). Just write a property as:
int iCanNameThisWhateverIWant;
public int SomeProperty {
get { return iCanNameThisWhateverIWant; }
set { this.RaiseAndSetIfChanged(ref iCanNameThisWhateverIWant, value); }
}
#2. Lack of documentation/samples
This is legit, but here's some more docs / samples:
http://docs.reactiveui.net/ (this is the official ReactiveUI documentation, a work in progress but definitely where you want to start)
https://github.com/reactiveui/ReactiveUI.Samples
https://github.com/reactiveui/RxUI_QCon
https://github.com/play/play-windows
#3. "I would have thought a far better approach would be to define a very simple interface and then provide extension methods within ReactiveUI to facilitate all the requisite overloads"
Implement IRxUILogger instead, it has a scant two methods :) ReactiveUI will fill in the rest. IRxUIFullLogger is only there if you need it.
"In addition, there's this weird IWantsToRegisterStuff interface "
You don't need to know about this :) This is only for dealing with ReactiveUI initializing itself so that you don't have to have boilerplate code.
"I suspect it would be horribly confusing having both intermingled in one's code base."
Not really. Just think of it as "MVVM Light with SuperPowers".
I am answering as someone who has used ReactiveUI in a few production systems, has had issues with the way RxUI does stuff, and has submitted patches to try and fix issues I've had.
Disclaimer: I don't use all the features of RxUI. The reason being I don't agree with the way those features have been implemented. I'll detail my changes as I go.
Naming. I thought this was odd too. This ended up being one of the features I don't really use. I use PropertyChanged.Fody to weave in the change notification using AOP. As a result my properties look like auto properties.
Doco. Yes there could be more. Especially with the newer parts like routing. This possibly is a reason why I don't use all of RxUI.
Logging. I've had issues with this in the past. See pull request 69. At the end of the day I see RxUI as a very opinionated framework. If you don't agree with that opinion you can suggest changes, but that's all. Opinionated does not make it bad.
I use RxUI with Caliburn Micro. CM handles View-ViewModel location and binding, Screen and Conductors. I don't use CM's convention binding. RxUI handles Commands, and ViewModel INPC code, and allows me to react to property changes using Reactive instead of the traditional approaches. By keeping these things separate I find it much easier to mix the two together.
Does any of these issues have anything to do with being production ready? Nope. ReactiveUI is stable, has a decently sized user base, problems get solved quickly in the google group and Paul is receptive to discussion.
I use it in production and so far RxUI has been perfectly stable. The application has had problems with stability, some to do with EMS, others with an UnhandledException handler that was causing more problems than it was solving, but I've not had any problems with the ReactiveUI part of the application. However, I have had issues regarding the ObservableForProperty not firing at all, which I may have used incorrectly and did work consistently (incorrectly) in my test code as well as in the UI at run time.
-1. Paul explains that the _Upper is due to using reflection to get at the private field in your class. You can either use a block such as below to deal with the StyleCop and Resharper messages, which is easy to generate (from the Resharper SmartTag)
/// <summary>The xxx view model.</summary>
public class XXXViewModel : ReactiveObject
{
#pragma warning disable 0649
// ReSharper disable InconsistentNaming
[SuppressMessage("StyleCop.CSharp.NamingRules",
"SA1306:FieldNamesMustBeginWithLowerCaseLetter",
Justification = "Reviewed. ReactiveUI field.")]
private readonly bool _IsRunning;
[SuppressMessage("StyleCop.CSharp.NamingRules",
"SA1306:FieldNamesMustBeginWithLowerCaseLetter",
Justification = "Reviewed. ReactiveUI field.")]
private string _Name;
....
or change your properties from the full
/// <summary>Gets or sets a value indicating whether is selected.</summary>
public bool IsSelected
{
get { return _IsSelected; }
set { this.RaiseAndSetIfChanged(x => x.IsSelected, value); }
}
to its component parts such as
/// <summary>Gets or sets a value indicating whether is selected.</summary>
public bool IsSelected
{
get { return _isSelected; }
set
{
if (_isSelected != value)
{
this.RaisePropertyChanging(x => x.IsSelected);
_isSelected = value;
this.RaisPropertyChanged(x=>x.IsSelected);
}
}
}
This pattern is also useful where you don't actually supply a "simple" property accessor, but may require a more derived variant where setting one value affects multiple others.
-2. Yes the documentation isn't ideal but I found that after Rx, picking up the RxUI samples was quite easy. I also note that the jumps from 2->4 seem to have all come with the changes to support Windows 8/Windows 8 Phone, and having picked up ReactiveUI for a Windows Store App then the DotNet 4.5 support is excellent. i.e. use of [CallerName] now means that you simply this.RaiseAndSetIFChanged(value) no need for the expression.
-3. I haven't any feedback on the logging side as I've not elected to use it.
-4. I've not mixed and matched with others frameworks either.
There's also a list of other contributors to ReactiveUI 4.2 at http://blog.paulbetts.org/index.php/2012/12/16/reactiveui-4-2-is-released/, including Phil Haack.
Is there a way where we can find out which UI element has posted an operation to the Dispatcher queue which eventually throws the event ,System.Windows.Threading.Dispatcher.CurrentDispatcher.Hooks.OperationPosted
Update : A private property DispatcherOperation.Name is showing what I need in the VS mouse-over in debugging mode. I just need to print this name to a logger for other debugging purposes. Is it possible to extract the Name dynamically.
Yes it is possible, while i give you a way to do it, i must warn you though, using reflection to get private or protected fields/properties/methods is never a good idea because first they are usually private for a reason and second of all if the signature or interface changes you code might break. But because you said it is just for debugging, this might be a valuable solution.
You can always use Reflection for these kind of things. First you need the Type and Instance of the object you want to read its private properties. Unfortunately i don't know if the Name you are looking for is a field or a property, but the overall procedure is similar. First get the property with GetProperty and then call GetValue on the returned PropertyInfo object. You might want to cache the PropertyInfo object to gain some speed while debug. You also need to use the correct BindingFlags again i don't know exactly how the field/property is described so i can't give you the exact code, but from here it should be easy to figure out.
Hope that helps.