I have a Dataset with several partial class definitions in the Dataset.Designer.vb file. They are all partial class definitions, for example: Partial Public Class ItemTable{}
The problem is that when I define the other partial class to extend the functionality, it has no access to the properties and functions that were defined in the original partial class.
The pictures below are of the first/original Partial class definition, and the one i created to extend it.... Why cant I access "Adapter"?
Related
Is it possible to get the whole view model in tag helper Process method (.NET Core MVC)?
Everything passed to the tag helper is done via attributes. If you want the whole view model, then you'd simply so domething like:
<mytag model="#Model" />
And then you'd need a property on your tag helper to bind this to like:
public MyViewModel Model { get; set; }
The name of the attribute corresponds to the name of the property. There's nothing special about "model" here.
However, the utility of that is going to be limited. Tag helpers are intended to be somewhat generic. That's the point: encapsulating reusable logic. If you tie it to a particular view model class (based on the property), then it will only work with that particular view model. The only way to make it more generic would be to use a base class or to literally type it as object, so that anything could be passed. However, with a base class, 1) you need to have every view model inherit from this base class and 2) even then, you'd only be able to use properties on the base class. With object, you wouldn't really be able to reference any properties unless you downcast it to a particular view model class first. While that would allow you to handle any scenario, in principle, you'd be forced to have long blocks of switch or if statements in your tag helper to conditionally handle different scenarios.
Long and short, it's not a great idea for many reasons to pass the whole model. The tag helper should have one specific purpose, and you should only pass things that are specifically needed by it, which also allows you to be explicit about those needs.
If you're looking for something to handle a whole model, you're more likely looking for a partial view or view component, rather than a tag helper.
The viewmodel is actually available if you bind first the for element as :
[HtmlAttributeName("asp-for")]
public ModelExpression For { get; set; }
Then you can access it in your tag helper Process or ProcessAsync through:
For.ModelExplorer.Container.Model
I am using FileHelpers class for dynamic generating the class
I got the result also but when I bind to property grid its not showing the nested object. Its says class need to have this attribute
[TypeConverter(typeof(ExpandableObjectConverter))]
But the class is dynamically generated through FileHelpers so how can I provide this attribute?
I even appended the string by fails fail to create the class now dynamically.
Please advise is there a way I can add this attribute to the class created dynamically through FileHelpers.
Say I have a class TestClass with the following definition:
Option Explicit
Public x As Variant
I want an instance of this class to be created when the workbook opens, and usable in other workbook events. So in the ThisWorkbook module, I add:
Public tc As TestClass
Private Sub Workbook_Open()
Set tc = New TestClass
tc.x = "abc"
End Sub
When I compile this, I get an error:
Private object modules cannot be used in public object modules as
parameters or returns types for public procedures, as public data
members, or as fields of public user defined types
I was able to resolve this by going to the Properties Window for TestClass and setting Instancing to PublicNotCreatable. It seems that this hasn't affected the behavior of the class or my ability to create local instances of it within various functions in this VBA project. Does changing this Instancing setting have any potential problems?
PublicNotCreatable is so you can use that class in a different VBProject. The NotCreatable part means that whatever VBProject hosts the class has to create any new instances and pass those to the other VBProject. The other VBProject cannot create them by itself.
What you want to do is Public tc As TestClass in a standard module and keep your class instancing Private. Declaring a variable public in a standard module makes that variable available everywhere in your project.
What you did is created a custom property of the ThisWorkbook instance of the Workbook object. ThisWorkbook is a class module (so are the sheet modules and userforms). Those class modules are special because they have a user interface component (workbooks, worksheets, and forms), but they're class modules all the same. You can define properties and methods in ThisWorkbook just like you do in a custom class. And that's what you did. You created a custom property called tc.
To create a property in a class, you can either use Property Get/Let or Public. The shortcut of using Public looks a lot like declaring a public variable in a standard module, but it's not quite the same.
So why the error? When your custom class instance is a property of another class, VBA won't let you create an instance of the custom class because you could end up with a child class and no parent class.
So keep your instancing private and declare your public variables in a standard module. I have a special module called MGlobals where I keep all my public variables. If I have more than a couple, I'm probably doing something wrong.
I am working on an MVC 4 website that makes use of areas, lets call it 'MyMVC'.
As in most MVC projects there is a folder called 'Models' in the root of the website.
Inside this 'Models' directory there is a class called 'MyViewModel.cs' which contains a public class called 'MyViewModel' with a namespace of 'MyMVC.Models'.
Now, in one of the areas, call it 'Area1', there is also the typical MVC structure that also contains a directory called 'Models'. It also contains a class 'MyViewModel.cs' which also contains a class called 'MyViewModel', this time with a namespace of 'MyMVC.Areas.Area1.Models'.
Inside a view I am working on that is inside of the 'Area1\Views' directory I have at the top:
#model MyMVC.Areas.Area1.Models.MyViewModel
#using MyMVC.Areas.Area1.Models
When I go to reference the the MyViewModel like so, for example:
MyViewModel mvm = new MyViewModel();
I get an ambiguous error and it thinks I am referring to the other MyViewModel class although as you can see I have clearly specified with the #model directive and the #using directive which one I am referring to.
Can anyone explain what the ambiguity is?
Can anyone explain what the ambiguity is?
The ambiguity is not in your view. It's in your controller code:
MyViewModel mvm = new MyViewModel();
If in this controller you have both:
using MyMVC.Models;
using MyMVC.Areas.Area1.Models;
it's more than obvious that the C# compiler has no way of knowing which class you are referring to. You could remove the ambiguity by fully specifying the name of the class:
var mvm = new MyMVC.Areas.Area1.Models.MyViewModel();
UPDATE:
You might also have the namespace referenced in the <namespaces> section of your ~/Views/web.config file which is effectively bringing it into scope globally in all your views.
Is it correct to store all my ViewModels in SimpleIoc? For instance I am having three pages MainPage, Photos, Directories (therefore three ViewModels -> MainVM, PhotosVM, DirectoriesVM). Should I set DataContext in each page to View Model Property in ViewModelLocator or nest ViewModels as properties in MainVM and bind each page DataContext to Main.PhotosVMProperty, Main.DirectoriesVMProperty and so on? Could anyone explain me idea and purpose of IoC ?
First, lets look at what ViewModelLocator does and why we use it:
ViewModelLocator is declared as an object on our App.xaml page and is an application singleton. We're going to have one, and only one of them available to the application when it runs.
ViewModelLocator is the source for all our ViewModels in MVVM Light. For each ViewModel we'll have a property on the ViewModelLocator that allows us to get a ViewModel for a View. This code looks like this:
public class ViewModelLocator
{
public MainPageViewModel MainPage
{
get { return new MainPageViewModel(); }
}
}
This is a piece of my App.xaml:
<Application.Resources>
<vm:ViewModelLocator
x:Key="ViewModelLocator" />
</Application.Resources>
This is a piece from View.xaml
DataContext="{Binding MainPage, Source={StaticResource ViewModelLocator}}"
So far so good. To answer your first question, do you have to use Ioc in MVVM Light? No. There's no need as your viewmodel will be given to your view fully built and instantiated by the ViewModelLocator.
Now, onto your second question: What's the purpose of IoC?
IoC is designed to allow you to do the following:
With Mvvm Light you do the above like this:
public class ViewModelLocator
{
public ViewModelLocator()
{
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
if (ViewModelBase.IsInDesignModeStatic)
{
SimpleIoc.Default.Register<IDataService, Design.DesignDataService>();
}
else
{
SimpleIoc.Default.Register<IDataService, DataService>();
}
SimpleIoc.Default.Register<MainViewModel>();
}
public MainViewModel Main
{
get { return SimpleIoc.Default.GetInstance<MainViewModel>(); }
}
}
public class MainViewModel
{
public ObservableCollection<Foo> Foos { get; set; }
public MainViewModel(IDataService dataService)
{
_dataService=dataService;
Foos=_dataService.GetFoos();
}
}
When I resolve my MainViewModel when I call
SimpleIoc.Default.GetInstance<MainViewModel>()
what happens internally is that the SimpleIoc checks to see if the MainViewModel has any dependencies (parameters in its constructor). It then tries to resolve these parameters by looking at the interfaces that have been registered with it. It does this recursively, so if DataService had a dependency it would be instantiated and passed to the DataService constructor when it was being instantiated as well.
Why would I do all this work?
Make your classes easily unit testable
Make your code interface-driven. This means that you're referencing interfaces rather than concrete classes
Make your code loosely coupled. This means that someone can change the implementation of an interface and classes that consume that interface don't care and don't have to be re-coded.
Resolve your classes dependencies in an automated way.
In MVVM Light, you'll see that it can tell when it's running in design-mode (ViewModelBase.IsInDesignModeStatic), this means that you can create design-time services to provide your viewmodels data so your View in Visual Studio contains actual data.
MVVM Light has a lot of nice features but it appears to me that the Service Locator creates unwanted dependency of the views on the view models. Ideally, I would like to have the ViewModelLocator in Library A, the view models in Library B and the views in Library C. Then I can mix and match these as needed for future projects. However, in the design of MVVM Light, as far as I can see, the views (Library C) will always have a dependency on the ViewModelLocator (this is okay) but because the ViewModelLocator (Library A) will always have a dependency on the view models (Library B), then the views will always depend on the view models (this is not okay because a view now must include all the view model libraries it was ever used with across all products).
I believe that Prism gets around this problem by using string keys somehow. Am I missing something?
Oops! I think I just answered my own question. The solution is to make Library A, the ServiceLocator, specific to a particular solution (product). It then contains a reference to the view models only for that solution. Then the views depend on this ServiceLocator which in turn depends on all the view models for that product. The final result is that the views depend only on the views models that it will be used with for that product. There is no problem with thee fact that we are duplicating the ServiceLocator for each solution because this module contains only code that is specific to the solution. The components of the ServiceLocator such as the SimpleIoc class are, of course, common to all solutions, but these have been factored out into reusable classes that we invoke in ServiceLocator.
To summarize things, the problem I am trying to solve is suppose that a solution has 6 view models, four of which are closely related and two of which are closely related. We therefore create two assemblies, each containing the closely related view models. Suppose we design a product that uses one set of view models and the solution is designed to run Windows 8. Now the views are all different and we want to re-use only one set (assembly) of view models. So we just create a new ServiceLocator assembly that points to this assembly of view models and also any others that we need. Our new Windows 8 views now depend on this new ServiceLocator assembly and only the view models that are used in our new product (solution).