I have recently upgraded a .net1.1 solution to .net2.0.
AS this is a very heavy GUI appilcation with loads of controls and many multithreaded operations that update the GUI.
While these operations worked seamlessly in .net1.1 it is throwing up Cross Threaded Illegal operations after the upgrade.
Considering the fact that tehre are numerous grids, buttons and status labels that need to be updated via these multi threaded operations, I decided to code for checking the InvokeRequired solution, however doing that for every control would probably not be the best way to go about it.
I was wondering if you could suggest a better way of how I can go about it or propose any OOPS based class structure that I could code around to make the code look better.
Please do let me know if my question is unclear.
Thanks in advance
Here's a good article about your problem:
http://www.perceler.com/articles1.php?art=crossthreads1
The quick and dirty hack is to disable the check altogether:
static class Extensions {
public static DisableCrossThreadCheck(this Control c){
c.CheckForIllegalCrossThreadedCalls = false;
foreach(var ctl in c.Controls) {
ctl.DisableCrossThreadCheck();
}
}
}
(in your form):
this.DisableCrossThreadCheck();
Related
I am looking into using one or other method and in particular method 2. Can anyone tell me the advantages and disadavantages of using the 2nd method over the 1st.
Method 1 - ViewModel.cs
PTBtnCmd = new Command<Templates.WideButton>((btn) =>
MessagingCenter.Send<CFSPageViewModel, Templates.WideButton>(
this, "PTBtn", btn));
Method 1 - MyPage.xaml.cs (SetLang etc.. methods in this file )
MessagingCenter.Subscribe<CFSPageViewModel, Templates.WideButton>(
this, "PTBtn", (s, btn) =>
{
Utils.SetState(btn.Text, vm.PT);
SetLangVisible(btn.Text);
SetLangSelected(btn.Text);
vm.CFSMessage = Settings.cfs.TextLongDescription();
});
or
Method 2 - ViewModel.cs (SetLang etc.. methods in this file )
PTBtnCmd = new Command<string>(SetMode);
private void SetMode(string btnText)
{
Utils.SetState(btnText, PT);
SetLangVisible(btnText);
SetLangSelected(btnText);
CFSMessage = Settings.cfs.TextLongDescription();
}
Would also like to hear comments on the idea of adding methods into the ViewModel.cs code. Would it be better for these to be in another file?
The MessagingCenter
helps you keep your code decoupled. Sometimes you will find yourself in a position
that requires you create a reference between certain code, but by doing so, you have to
compromise on reusability and maintainability.
Try to use it as a last resort; usually there is
another way to achieve your desired functionality. While sending a message can be very
powerful, using it too much can really eat into your readability.
A use case example for MessagingCenter would be a case where you need to update values in multiple
parts of your app. You can subscribe to a message from multiple places and thus execute
code in multiple places when a message is received. Another use case could be if some
background process is done, it can send a message and you can then inform the user in
your UI.
I would not use the messaging in the VM layer because your VM layer can then only be used in Xamarin.Forms. Some Mvm frameworks, like mvvmlight, offer a messaging capability. I would opt for that instead as you could then reuse your VMs in Wpf, Uwp or other UI frameworks other than XF.
Also i wouldn't use the messaging like you have. If probably just use databinding and raise PropertyChanged events in the VM which the view can react to.
To pass data between VMs I'd suggest navigation params or rethinking how you are using this data in general (use some sort of service or dumb down the UI depending on how "fat" your client app must be).
Messaging center as #Andy mentioned would cause reusability issues but this does not mean that you cannot use it. My approach is wrapping it in a separate service and using it in implementation. This will let you to do two things: creating more convenient or better way to use it in accordance to your use case and an option to swap out the implementation of your messenger to any other pub-sub library (or your own impl.) if you will need to use these VMs in WPF project.
Of course using something more universal across platforms would be a great option too but it also depends on how much you are "allowed"/can use third party stuff. At least with MAUI this causes some problems, but this is for another topic.
I'm working on an eclipse RCP application, using a third-party domain model based on EMF, and a GEF editor for editing.
GEF uses the MVC pattern, which would be fair enough if I didn't have to use a specific layout for drawing the model graph on the editor view. The domain model I am using includes no visual information whatsoever (which in itself is a good idea), but I'd like to be able to assign coordinates to Figures in their EditParts. This would make it much easier for me to calculate the position of the figure in the layout.
Now I have stumbled upon the Presentation Model Pattern by Martin Fowler, which seems just about the thing I was looking for. I have also found a - old-ish - tutorial on RCP UI testing (German only), which uses this pattern in an eclipse RCP context.
Now I'm wondering: is it generally possible to use PM in a GEF context, seeing that GEF explicitly uses MVC? Is MVVM an alternative?
Please note that I am prevented from using GMF for a number of reasons.
Many thanks!
Yes, it's definitely possible, and you have two choice.
First - is implement you own graphical notation model. I would suggest you using appreach like:
modelElement : ModelElement 1..1
x : int 1..1
y : int 1..1
Then load two models in EditingDomain (EMF will resolve cross-document references for you), create all missing Graphical Notation Elements e.t.c...
The other option is to use GMF or Graphiti. They have the model you're looking for out of the box, which will greatly simplify you life. At the cost of learning yet-another-monster-framework (in case of GMF). Graphiti, is easy (relative to GEF/GMF), but IMO is's less flexible. GMF, btw, will give you a 'free' TransactionalEditingDomain, which will handle all the commands, undos and redos for you. So, as in comments to you previous question, I would suggest you using GMF.
Oh, sorry, I didn't noticed what you wrote about GMF.
Then, the second option is to have Graphical Model inherit from Domain Model, and then code you GEF editor against this model.
Some of my coworkers consider validation as an example of a cross cutting concern and think Aspect Oriented Programming is a good way to handle validation concerns. To use PostSharp notation they think something like this is a good idea:
[InRange(20.0, 80.0)]
public double Weight
{
get { return this.weight; }
set { this.weight = value; }
}
My opinion is that validation is an inherent part of an algorithm and there is no need to push it behind the scenes using AOP. However it is much like a gut feeling and I have not a very clear justification for it.
When do you think it is a good idea to handle validation with AOP and when it is better to handle it inline with your main code?
Looks a lot like Microsoft DataAnnotations as used by MVC.
You aren't really "pushing it behind the scenes", since all the relevant information is right there in the attribute constructor. You're just pushing the noisy boilerplate behind the scenes and into its own class. You also no longer need an explicit backing field, and you can just use auto-getters and setters. So now, 8 lines (or more) of code can be reduced to 1 line and 1 attribute.
I think that if your alternative is to put some validation code inside of the setter, and you do that multiple times in your project to where it becomes repetitive boilerplate, then yes, I think it's a valid cross-cutting concern and appropriate for using PostSharp. Otherwise, I don't think one or two places justify bringing in a third party tool just yet.
I'd think that it is a cross cutting concern although i have never implemented it with AOP specifically.
That said, there are many different validation scenarios and I doubt they can all be exactly black or white.
Microsoft Patterns and Practice - Cross cutting concerns
I have been working with Coded UI Test(CUIT) feature of VS2010 .
When recording the CodedUI framework generates a lots of hierarchical classes.
I was wondering whether coding(by hand) a CUIT would reduce the code created and would it be as optimized(in searching elements) as generated code??
Also what are the scenarios where a CUIT could be coded by hand?
CUITe (Coded UI Test enhanced) Framework is for people who prefer hand coding.
http://cuite.codeplex.com/
CUITe is a thin layer developed on top of Microsoft Visual Studio Team Test's Coded UI Test engine which helps reduce code, increases readability and maintainability, while also providing a bunch of cool features for the automation engineer.
CUITe allows you to define a much simpler Object Repository (== UIMap). Each page/window will be defined in a separate class file, and each UI control definition will be just a one liner. You can move common controls to a parent class which increases maintainability. You can also categorize the page/window definition classes into different folders as you deem fit.
I have been working on Coded UI, from my understanding recorded/generated code is too complex and difficult to maintain.
I always use hand coding, which is simple and easy to maintain.
Here is full sample hand coded UI script for Silver-light application
[TestMethod]
public void SilverlightHANDCODINGTest()
{
BrowserWindow br = BrowserWindow.Launch(#"http://localhost:1377/SilverlightApplication1TestPage.html");
UITestControl sCustom = new UITestControl(br);
sCustom.TechnologyName = "Web";
sCustom.SearchProperties.Add("ControlType", "Custom");
sCustom.SearchProperties.Add("TagName", "OBJECT");
sCustom.SearchProperties.Add("Type", "application/x-silverlight-2");
sCustom.SearchProperties.Add("TagName", "OBJECT");
// sCustom.DrawHighlight();
SilverlightControl sframe = new SilverlightControl(sCustom);
sframe.TechnologyName = "Silverlight";
sframe.SearchProperties.Add(SilverlightControl.PropertyNames.MaxDepth, "-1");
sframe.DrawHighlight();
SilverlightEdit sTextBox = new SilverlightEdit(sCustom);
sTextBox.TechnologyName = "Silverlight";
sTextBox.DrawHighlight();
Playback.Wait(2000);
sTextBox.SetProperty(SilverlightEdit.PropertyNames.Text, "Thank god");
SilverlightButton sButton = new SilverlightButton(sCustom);
sButton.TechnologyName = "Silverlight";
sButton.SearchProperties.Add(SilverlightButton.PropertyNames.DisplayText, "Button");
sButton.DrawHighlight();
Playback.Wait(2000);
Mouse.Click(sButton);
SilverlightComboBox sComboBox= new SilverlightComboBox(sCustom);
sComboBox.TechnologyName = "Silverlight";
sComboBox.DrawHighlight();
Playback.Wait(2000);
sComboBox.SetProperty(SilverlightComboBox.PropertyNames.SelectedItem,"Kishore");
}
Thanks,
You may hand write less code but its going to likely be less maintainable and more prone to breaking. You can use the partial class to effectively override the search clauses after the code has been generated.
What are the best practices when creating a Magento extension to avoid conflicts with other extensions that get loaded to a store. I know how to code with the override method, observer methods and the details behind how to do that the preferred way. That still doesn't stop you from having conflicts with other modules out there and upgrades.
Alan Storm, if you read this, I also have read your recent post about overrides and upgradability. Is that the best way to think for this type of situation as well? I also see extensions and articles people have created to allow multiple classes extend the same class.
The best possible way to avoid this problem is to use the Observer pattern built into Magento whenever possible. It's not in nearly enough places, but when you have the option, using it will let you play nicely even with other poorly behaved extensions.
Nextly, try to override the minimum number of classes. It sounds obvious, but there have been times when I've thought it was necessary to override every one of the shipping calculator classes (the code was easy, but needed to be repeated). With some more work, I was instead able to override a single class and save myself some maintenance headache to boot.
When you do this, you may still run into conflicfts with other extensions overriding the same classes you are. This is unfortunately not a solved problem in Magento, and there isn't a great way to resolve it other than contacting the person in question and hashing out a solution.
Finally, to the problem of upgradeability, a common problem I see in people's code is that they, without thinking, override an entire function when it isn't necessary. So you get this:
function doSomethingUseful() {
// ...100 lines of parent code...
unset($result['badKey']);
// ...100 lines of parent code...
return $result;
}
When you go to upgrade a site, that's 200 more lines of code likely to cause a bug. Bad times! Instead, something like this often works (and is an easy improvement):
function doSomethingUseful() {
$result = parent::doSomethingUseful();
unset($result['badKey']);
return $result;
}
It's faster, it's more readable, it's less error prone, everyone wins!
Hope that helps!
Thanks,
Joe