Loading existing data into MonoTouch.Dialog - xamarin.ios

I am new to MonoTouch from a VS/C# background and am trying to rewrite an existing c# app.
I have made one simple MonoTouch app which succesfully loads data into a List<> from an XML file, and was starting to add Master/Detail code when I discovered the existence of MonoTouch.Dialog which looked like it would make my job much easier. So I started a new project using the sample code at http://docs.xamarin.com/ios/tutorials/MonoTouch.Dialog , changing the basic class to match what I needed.
But I am stuck with trying to prepopulate the DialogViewController with my existing List<>. I have tried using LoadMoreElement but cannot find an example of its use and don't know if it's the best way of doing this.

Thanks Anders.
In the interim period I discovered a different method:
_rootElement = new RootElement ("Riders")
{
new Section()
{
from x in riderList.Riders select (Element) new RootElement(x.Name)
{
new Section()
{
new StringElement("Rider",x.Name),
new StringElement("Club",x.Club),
....
....
...ill try both and see what suits best.
But I'm struggling to find any documentation to describe the methods for the dialog classes, e.g. Section.AddAll() and others used in the link you have provided.

If you want to create a list within an existing dialog view, you can for example create an empty Section and to this section add the list the elements from the list as RadioElement:s or CheckboxElement:s, depending on how many elements you want to be able to select simultaneously.
To facilitate selection, you may need to create a Group/RadioGroup and reference this group when you create the respective list elements in your section.
Here is a quick example of creating a new Section and adding the list elements, assuming that only one element can be selected simultaneously:
var list = new List<SomeClass> { ... };
var listGroup = new RadioGroup("grp", 0);
var listSection = new Section();
listSection.AddAll(list.Select(elem =>
new RadioElement(elem.ToString(), "grp") as Element));
If you want more specialized handling of the elements in the list or the events associated with list actions, you may want to subclass RadioElement or CheckboxElement. There is a good example on how to do this in the answer to this SO question.

Related

Display custom product association data in a new tab

I wrote an extension to add data to the ProductEntity in Shopware 6 and used the following tutorial:
https://developer.shopware.com/docs/guides/plugins/plugins/framework/data-handling/add-complex-data-to-existing-entities
I also used another tutorial (https://developer.shopware.com/docs/guides/plugins/plugins/administration/add-new-tab) to add a new tab to the product detail view. Everything works so far.
In the product detail view I added a text field in my custom tab. But my problem is: how to get my data into the view? I want to add my new association to the product when the detail view is loaded. Therefore I tried to override the component from Shopware as follows:
Shopware.Component.override('sw-product-detail', {
template,
mounted() {
const criteria = this.productCriteria;
criteria.addAssociation('myNewAssociation');
this.productCriteria =criteria;
},
});
This does not work because productCriteria has no setter (original component can be found here: https://github.com/shopware/platform/blob/6.4.1.0/src/Administration/Resources/app/administration/src/module/sw-product/page/sw-product-detail/index.js)
Does anyone know how I can add a custom association to an existing one in vue.js in Shopware 6? What's the correct way to inject a custom association to the product detail view so I can use data from that in my new custom tab? The documentation always stops when it becomes interesting...
I would suggest to overwrite the productCriteria method and call the parent to not need to fully copying the existing code, like this:
Shopware.Component.override('sw-product-detail', {
template,
computed: {
productCriteria() {
const criteria = this.$super('productCriteria');
criteria.addAssociation('myNewAssociation');
return criteria;
},
},
});
Let me know if it works.
I believe also you don't need to mention the template in the override (when I did this last time, the template was displayed twice)
EDIT: All good with the template.

How do I add a Lead Source option

I'm trying to add options to the Source dropdown on the Leads screen. The field uses the CRMSourcesAttribute class to define the existing list. After simply creating a new attribute class to add my own items, I extend the CRLead.Source CacheAttached event to use my new attribute class instead. The result is that there is no change - the new dropdown items are not shown. After doing this, if I inspect the field and select the Drop Down Values button, I do actually see the new options in the Drop Down Values popup window. Any ideas on what could be preventing the new options from displaying in the dropdown itself?
Here's how I configure it in my LeadMaint graph extension:
[PXMergeAttributes(Method = MergeMethod.Append)]
[PXRemoveBaseAttribute(typeof(CRMSourcesAttribute))]
[CRMSourcesExt] // list with old + new options
protected virtual void _(Events.CacheAttached<CRLead.source> e) { }
(v20R2)
Another option is to use code and create a new attribute class with new options, then override the DAC field to use it instead. However, as far as I know, you still have to go through the steps of activating the new options in the workflow customizations UI for each of the fields you're overriding. But then you can refer to the new options in code without having to search the list's AllowedValues at runtime.
With help from a colleague, I was able to get it working, and “without code” through screen workflow customization. I removed my code, then customized it with a new custom Workflow copied from the default. Not sure yet of the ramifications of this, like if we can access the new options in other real code or not, but I see how to create these options now. It has to also be done for both Lead and Opportunity in this scenario. It’s a bit tedious and ethereal (good word) though. I can see this easily causing problems and unexpected results for us we’ll want to watch out for.
Update 5/28/21: I added the options in the Workflow customizations for the field, then copied the default workflow to a new workflow, activated it, and activated the new options for each state/transition. I don't like it, but Acumatica tells me "that's just the way it is now". Note: you'll want to do this for other places referencing CRMSourcesAttribute as well, such as Opportunity.

create or inject ViewModel when building a "tabs" application

We try to build an application with a few tabs. As reference-project we use that example: http://slodge.blogspot.co.uk/2013/06/n25-tabs-n1-days-of-mvvmcross.html
To get the ViewModel-instances we need to create the tabs, we used the "HomeViewModel"-pattern as mentioned in that post: Create View Model using MVVMCross built in factory?
What I don't like at this approach is the initialisation of ViewModel's with "new". As far as I understand, it skips the whole ViewModel-Lifecycle (https://github.com/slodge/MvvmCross/wiki/View-Model-Lifecycle) which we really like. In our current project, we'd like to use the "start()" lifecycle-method, but it's never called due to initialisation with "new".
What worked for us was to go that way:
var loaderService = Mvx.Resolve<IMvxViewModelLoader>();
var vm = (UserListViewModel)loaderService.LoadViewModel(new MvxViewModelRequest(typeof(UserListViewModel), null, null, null), null);
So my question: Is that the way to do the job or is it just a dirty workaround and there is a much better solution?
Update: We came to that solution:
CreateTabFor<SettingsViewModel>("Settings", "settings");
//This method loads the ViewModel
private UIViewController CreateTabFor<TTargetViewModel>(string title, string imageName)
where TTargetViewModel : class, IMvxViewModel
{
var controller = new UINavigationController();
controller.NavigationBar.TintColor = UIColor.Black;
var viewModelRequest = new MvxViewModelRequest(typeof(TTargetViewModel), null, null, null);
var screen = this.CreateViewControllerFor<TTargetViewModel>(viewModelRequest) as UIViewController;
SetTitleAndTabBarItem(screen, title, imageName);
controller.PushViewController(screen, false);
return controller;
}
The 'viewmodel lifecycle' is an area of conflicting interests in MvvmCross. The root cause is the conflict between:
viewmodel's which are just the models for any view
viewmodel's which are specifically used within the 'ShowViewModel' navigation process
For simple 'whole page' User Experiences, the C-I-R-S viewmodel lifecycle is easy to support and to ensure it gets consistently used.
However, as soon as the user experience starts to merge in tabs, flyouts, hamburger menus, dialogs, split views, etc then:
the developers sometimes want to control viewmodel lifecycles themselves
it's not as easy for the framework to ensure that view models are always created, activated and tombstoned/rehydrated consistently
Personally, I like your approach - of trying to ensure all viewmodels are independent and all constructed the same way - but MvvmCross doesn't force this approach on all developers.
Specifically for tabs, most of the existing examples do use the 'owned sub-viewmodel' pattern that you've identified.
However, it should be relatively easy to implement other mechanisms if you want to - just as you already have.
In particular, you can:
use the loaderService directly - getting hold of it via Mvx.Resolve<IMvxViewModelLoader>();
use ShowViewModel with a custom presenter to create both views and viewmodels - the beginnings of this is illustrated in that N=25 video but you could take it much further and actually add the tabs in response to ShowViewModel calls.
use alternative calls to create the child tabs and their viewmodels inside the Views - e.g. where the Touch sample currently calls
var screen = this.CreateViewControllerFor(viewModel) as UIViewController;
this could easily be replace with something like:
var screen = this.CreateViewControllerFor<ChildViewModel>() as UIViewController;;
(or one of the other overloads from MvxCanCreateIosViewExtensionMethods.cs)
One repo where I know some users have taken some of these ideas and played with them is the Sliding menu repo - I think they have chosen to use this.CreateViewControllerFor<TViewModel> to create their view models. This may or may not be the way you choose to go - but it might be of interest for you to experiment with.

What's the best practice to creating different views when sharing one child frame in an MFC MDI app?

I'm not necessarily looking for code help, but rather a high level answer so I can research the solution myself. Basically, I have an MDI app with multiple docs and their views, I'd like all the views to open up as tabs in the one child frame that I have. The thing is my child frame is statically configured with a splitter window with two views, a form and a list view, in the OnCreateClient method. I'd like to keep this as the default tab that appears when the app is launched.
I have a third view (editview) with it's own document template, which I'd like to be able to open as a separate tab. I will have other views that will behave this way. What's the best way to approach this?
Will I need to create separate child frames for each view? Will I lose the 'tab' feature if I create separate child frames?
Or will I have to modify the child frame's OnCreateClient method to test which document template is the current one and create the view for that doc template? I'd like to know how some of you seasoned programmers have had or would do it.
Thanks.
In case this helps others, from what I've gathered, it is perfectly acceptable to create a new child frame class derived from CChildFrame or just use that as your frame with your new view. The doc, frame, and view will be added to the doc template in the initInstance method. for example, let say you have a pair of trios (2 docs, 2 views, 2 frames):
pDocTemplate = new CMultiDocTemplate(IDR_testappTYPE,
RUNTIME_CLASS(CMydoc1),
RUNTIME_CLASS(CMyframe1),
RUNTIME_CLASS(CMyview1));
if (!pDocTemplate)
return FALSE;
AddDocTemplate(pDocTemplate);
pDocTemplate2 = new CMultiDocTemplate(IDR_testappTYPE,
RUNTIME_CLASS(CMydoc2),
RUNTIME_CLASS(CMyframe2),
RUNTIME_CLASS(CMyview2));
if (!pDocTemplate2)
return FALSE;
AddDocTemplate(pDocTemplate2);
If you add another trio with a different childframe because this new frame doesn't use splitters like the ones above, you would do it this way.
pDocTemplate3 = new CMultiDocTemplate(IDR_mditest3TYPE,
RUNTIME_CLASS(CMydoc), //same doc
RUNTIME_CLASS(CMyframeWithoutSplitters), //new frame
RUNTIME_CLASS(CMyview3)); //new view
if (!pDocTemplate3)
return FALSE;
AddDocTemplate(pDocTemplate3);

How to add found item to a QListView using Qt?

I am trying to implement search option for my file browser application.
I can get the item after taking an input from the user. Now, I want to add this item to my listview. Also after the search is over, the item should be clickable to open them.
Here, is the piece of code... Any suggestions will be appreciated.
void Browser::search()
{
QDirIterator it(path,QDir::AllDirs|QDir::Files|QDir::NoSymLinks|QDir::NoDotAndDotDot,QDirIterator::Subdirectories);
while(it.hasNext())
{
it.next();
if(it.fileInfo().completeBaseName().contains(content,Qt::CaseInsensitive))
{
qDebug()<<"it.fileinfo = "<<it.fileInfo().fileName();
}
}
path.clear();
}
Instead of List View you can use List Widget and simply fill the list using method addItem or addItems. If your list is small/simple it doesn't in my opinion make sense to use Model-View paradigm.
Look at QListWidget in documentation
You should read more about model/view concept. You add data to your model not to a view. You'll find in this article sections "Editable items" and "Resizable models", which address your issue.

Resources