I want to save myself some time (I have two weeks of my internship left) by creating a simple reusable component based on a Region I created for a reporting page.
It consists out of a Static Region with the collapsible Template, containing 3 very similar Diagrams.
There is one Value which is the same for all 3 Diagrams, and 2 Values I need to change for each diagram.
Any tips how to reach that goal? Copying is dreadful, since I need that component 19 times on this page. I have no experience with creating plugins for APEX.
if you have already created the region you can duplicate it as many times as you like on that page by right clicking the region in the Rendering Tab on the left side of Page Designer and clicking the Duplicate option from the menu:
This is a lot faster than recreating the region from scratch each time. You can also do this to duplicate buttons, page items and dynamic actions.
Related
In Netlogo how can I make a second page to the interface, or a pop-up HUD (Heads up Display), to store widgets that I don't use frequently and simply clutter up the main interface?
Rationale: multiple widgets ( sliders, switches, etc.) are helpful for SETUP but then I'd like to hide them to keep the interface clearer, smaller, and less overwhelming to viewers.
Volker Grimm suggested that a set of tabs, each opening a pop-up window to manage different portions of complex models would be helpful.
Since the pop-up might have its own viewing area, you could use it to visually adjust parameters, such as a Normal or Poisson distribution that you want to use for input, without having to use your main interface's viewing area to accomplish this.
In fact, being able to open a second ( or Nth ) graphics window ( "world") into your model could be helpful
Preferably the pop-up would have persistent memory and could be hidden or shown with a single click.
Here's my own solution to the pop-up HUD question.
I used the LevelSpace extension ("ls") in the main model to pop up a second model containing the widgets I'm trying to show or hide as desired.
The main model has more details about how this works in the INFO tab.
In this prototype proof-of-concept, the main model simply displays a few turtles wandering around the world and has hide/show buttons to pull up the HUD.
The HUD has 3 sliders that can be used to set the number of turtles, size of turtles, and shape of turtles, and a button to upload those new settings all at once to the main model. The main model will check once every GO step for updates and apply them and mark them applied.
Alternatively, the HUD can be set to be in automatic-update mode, so the sliders are basically live and as you move each one the changes immediately show up in the main main model ( at the next GO step ).
It works! The full models with the interface buttons and INFO tabs are in the Netlogo Modeling Commons as "Popup-HUD part 1 of 2" and "Popup-HUD part 2 of 2" for download. ( just search for "HUD" as there are only two hits. )
They won't run over the web because they use the LevelSpace extension which isn't available there. You need to download the main model to be able to read the INFO tab.
These are free to copy, modify, etc. so long as attribution is made ( CC 4.0 )
I just discovered QField and I amazed by its features! Now I am trying to create a project that will fit my needs and have come quite far. I just have one questing on adding features in the app:
When adding a feature in the Qfield App in my project, everything is on one page and I have to scroll down in order to reach all input fields. This can be quite tedious while working in the field.
In the documentation and the demo project, that follows when downloading Qfield from Play store (offline_bees.qgs), the input is split up into sub-menus which you can reach by scrolling sideways (see image). This is much more effective than having everything on one page and having to scroll downwards. Unfortunately, I haven't found out how you can split your feature into such sub-menus as seen here. I have played a bit around with the available input widgets in the attribute form, to no avail.
I have also read the available documentation for Qfield 1.0 multiple times, but since I am neither a frequent user of QGIS nor a programmer, it is a bit challenging for me to understand the instructions (https://qfield.org/docs/project-management/vector-layers.html). Does it have something to do with the Relation Widget or Relation Reference?
I am thankful if somebody could point me in the right direction.
Looks like I didn't play around enough. I found out how to solve my problem. Here are the instructions
In QGis while preparing the project for QField:
Go to layer properties/ attribute forms
Set to "Drag and drop designer" (I failed to find this at first)
Create groups (these will be the sub menus) with the "+" button
Drag and drop your fields into the created groups
I am working on an input form with 218 input controls divided over 20 sections.
What I did is to create a ViewModel for each section and define with a DataTemplate how it is supposed to look.
The main page for the form is a grid of tiles. A tile per section.
A section is a page in a FlipView where you can flip from one section to the next. A click on one of the tiles jumps directly to a page in the FlipView. Some sections contain a Pivot control that allow the creation of multiple items (i.E. persons). If the content in the Pivot is long, it needs a ScrollViewer. Pivots and ScrollViewer don't go well together. Scrolling does not work.
There is a SO question and answer that adresses this: Pivot inside a ScrollViewer, scrollviewer wont scroll
The UWP Style Guide says
Rather than overwhelm the screen with numerous input controls,
consider creating multiple pages for your form.
But it does not say how the pages should be organized.
So given a gigantic input form with 218 input controls and 20 sections where some of them can add multiple items, is there a better way to organize the form than what I attempt to do (FlipView, ViewModels, DataTemplates, Pivot, ScrollViewer)?
If the sections don't need to be filled out in a specific order, I suggest that you use the NaviationView class and group each section as a Page. The end result could be similar to the Settings app which has a number of disparate sections.
If the forms need to be filled out in a specific order, use the Frame/Page navigation and provide previous/next buttons on pages.
Here's the issue, I build a special book reader/browser (For holy quran), my code behind loads the page and constructs how it should look. and then it should bind that look to a some kind of data-bindable custom control to view it properly. the problem is, the look differs from page to page, so I cannot bind to a certain control or wrap panel.
here's how it generally looks:
The decorative border top of the page is always there at any page, it indicates the part and chapter the viewer is in.
If you're starting a new chapter it have additional image under that decorative border or anywhere in the page (there can be multiple chapters in the same page) something like this
or this:
The normal text is not an issue, it's just a special font, however, I put each individual word in its own text block for reasons of user selection by word.
The issue here is, given the previous information, and knowing how random it is to place the decoration picture or the amount of words (text blocks) per page. how can I bind that to some kind of view to separate the view from the VM and Engine that builds the page.
my past solution was to actually build everything in the VM in a wrappanel built inside a scrollviewer having lots of textblocks and images according to the page. but that's naiive solution. I want to rebuild that in a more professional separated way. I also want to do this for Windows RT beside Windows phone so I need to reuse the code behind in a Portable class library.
I think all you need to do is slightly adjust your current design. So perhaps have a VM that represents the entire content, and that would have a Collection of say Pages or Sections. A second VM would represent the Page/Section, allowing you to create a property for the WrapPanel content (i.e. the words) and another property for the Header and or other things.
In the View you would have the scrollviewer and bind to the main VM collection. Then create another View or DataTemplate that represents the Page/Section.
You should be able to do this is a strict MVVM sense quite easily and it will be dynamic based on the content.
You could even cater for advanced scenarios where each section has a different template/view.
My understanding of GWT's Activities and Places is that for a given region on a screen you have an ActivityManager and an ActivityMapper. You can have multiple regions on the screen which means you can have multiple ActivityManagers and ActivityMappers (one per region). So, whenever there is a PlaceChange the ActivityManagers ask their respective ActivityMapper what activity it is supposed to be showing given the Place. This works great as long as your Places all have a common layout that they reuse in different ways to perform different activities. My question is how do we handle the case where different Places use radically different layouts? My first thought is to just have even more ActivityManagers and ActivityMappers, if the Place doesn't use a particular region then the ActivityMapper for that region will simply return null when we change to that Place. If there is a better way I would appreciate any wisdom.
I found it much easier to use a single ActivityMapper/ActivityManager pair for the entire app.
In a typical case you have a "menu" region and a "main" region. The menu region is very basic: a click on a menu item sends a user to a new place. It also highlights the newly selected item and resets the style of the previously selected item. All of this can be easily done in a simple widget that you can include in all views where this menu is required. Having separate ActivityMapper and ActivityManager for the menu region just complicates everything without providing any benefits.
I use the same approach for "top menu" region and "left menu/tree" region: a widget that tells the presenter which data to show in the "main" region.
I have over 50 different places in my app, and it really helps to have a simple architecture: each place corresponds to one view and one activity.