a quick question on creating forms. I would like to know how to remove the what seems to be a "locked grid" on my fields when creating a form. In essence, when i create forms, all my fields seem to be linked and when I adjust the length or width of one, they all adjust respectively making it impossible for me to tailor my form to my needs. It seems to me that the only option around this is creating a form from scratch and inserting field by field. There must be a quick way to disactivate this feature once the fields are created within the form.
Thanks,
A
Select the Arrange tab from the Ms Access Ribbon.
Then, when your "locked grid" is selected press:
Related
I am starting to build an app, using Meteor, that includes user-populated company profiles (including both financial data and text). I will be looking into a datafeed for public company information but much of the information for private companies will be user-populated.
I know I will need to create a form for the user to fill in so that the company information will be captured by the database. However, can I make this same form available to the user to both display the data and to allow them to edit the data in the future? Or do I need to build a separate view using tables for this purpose? My preference is the former, just one screen to create and edit as needed.
Any examples of similar instances would be very appreciated.
Thank you.
This is less of a meteor specific question, rather a general web technology question. Meteor can provide the data in the template of course, and it can offer events to process data and insert/update this to a database. This is the same as any underlying architecture. The question is really how to approach the problem with HTML & JavaScript.
A couple of potential methods:
Write your HTML to display the content in its non-editable form. Then provide an edit button to switch mode. When clicking this button switch on 'contenteditable' for the elements you wish to be edited: http://html5doctor.com/the-contenteditable-attribute/
Also reveal a save button, then process the event through meteor. Use selectors to extract the fields by referencing either designated class names, data attributes or name attributes. It would also be a good idea to alter the appearance of editable elements with a background or outline. The disadvantage here is that it's slightly non-standard and you may have the need for more complex data-types like dropdowns or checkboxes etc.
Create view with a standard form HTML. Style it in a way that shapes the information primarily for display rather than editing, eg. hide form field borders. Provide an edit button that when clicked alters the CSS and reveals form field borders, also reveal/replace elements which need more complex controls like dropdowns, perhaps turn on field labels too and of course a save button. The disadvantage is slightly more complex CSS and JavaScript.
Is there any specific reason not to use QAbstractItemView::setIndexWidget for an editor in a QTreeView?
I am having a hell of a time using QStyledItemDelegate's and setItemDelegateForColumn, with data not showing up in editors, checkboxes not replacing the checkbox from QAbstractItemModel.data(index, role).
The docs say not to use it but not why.
Actually docs do not tell to avoid using it at all, but make decision, based on your application behavior. Here is the quote:
This function should only be used to display static content within the
visible area corresponding to an item of data. If you want to display
custom dynamic content or implement a custom editor widget, subclass
QItemDelegate instead.
I've highlighted the key words that define in which cases you have to use which approach.
I'm currently working on a Symfony2 project. I've set up a form with a select field and some options loaded from the database. Now I want to add a data attribute to every option of this select field which is needed by a JavaScript.
I know how to make "static" changes to the form layout, however I need a different attribute for every option now - what changes do I have to make in my twig template?
Found a solution that fitted my needs here: https://github.com/symfony/symfony/issues/3836#issuecomment-23145270
The template is not the best place to do this. Instead, modify the form before presenting it. See How to Dynamically Modify Forms Using Form Events. Lots more flexibility there.
I have a checkout page on my site which lists items that customer is purchasing... and below the basic list is a "Detailed Invoice" section where they can see specific info on each. Up 'til now I only had two different types of items that could be purchased, so the detailed listing was fairly easy to handle. Now I'm adding four additional and completely different things that are purchasable... so the question: What is a good way of handling this sort of rendering using Sitecore sublayouts? (Currently, I just use a Repeater and hide/show appropriate fields)
The good news is, for each line item in an order there is an associated Sitecore Item instance. If the Sitecore API was better suited to object-oriented methodology, I might create a Render() method on each of my object types in question. But of course they are each Sitecore.Data.Items.Item objects. Subclass Item? This seems like overkill for just this task...
Something I've considered is a Sublayout/user control for each different item type... and then dynamically add them to a Placeholder on the invoice page. This seems reasonable... Thoughts? The downside is then the ugly code that has to match up the user control with the item... based on TemplateID maybe?
Anyway, just looking for some suggestions here.
Building classes to represent Sitecore data is not an unreasonable idea. This is a perfect scenario to to do it. Whenever I build project I always have classes generated using the Custom Item Generator in case I need template-specific field access. I also do everything as sublayouts so I can see your dilemma.
Are all/most of the fields unique to each product? You don't have a generic product template that each product instance uses?
These are the options I can think of myself (worst to best IMO):
Create a class to represent each unique template. The Custom Item Generator may work, but it may confuse you the first time. You can always make your own classes where you pass the Sitecore item into the constructor and create properties to access fields. Then use regular .NET controls and bind data to the front-end based on which template your item uses and using the strongly-type class for the template. This will likely be messy code of many if-else's.
Create a unique sublayout for each unique template in Sitecore. In your repeater that loops over the items, based on which template the item is, add the right sublayout to the placeholder using new Sublayout() and set the DataSource as the Sitecore item (here's code to access the DataSource). That way you abstract the implementation to each unique template.
Create classes for each template as mentioned in #1, but abstract across them all with an interface. In your repeater's ItemDataBound, implement data via the interface. This highly depends on how the fields compare and contrast from template to template. If you can force yourself to reduce the unique fields into the interface's members then each class that represents a template can just implement your interface. This allows for the future addition of more unique templates, as long as you continue to implement the interface.
This to me seems like a good place to use the "Presentation Inversion of Control" Sitecore pattern (as named by Aware Web).
http://www.awareweb.com/AwareBlog/Presentation%20Inversion%20of%20Control%20part%202.aspx
Though the blog post discusses this more in a context of user-placed items, it works here too. If you have a template for each product type, you could define presentation details on each (perhaps in a separate Device) that define the control which can render that item in the cart. Then you can read the RenderingReference's off the item, and place them into the page. This makes for a flexible, extensible system that allows you to handle different output for different types of products.
This is close to the solution you describe (Sublayout for each product type), but allows the sublayout to be data driven instead of conditional logic for each TemplateID. (Note you will need to assign a dummy "main layout" in the presentation details as well.)
I am creating a form that needs to have 30 or more fields either disabled or set to be read only. They need to be marked as such if the based on the value of a drop-down box.
This is something that I can do using conditional formating that I know, what I want to know is there a way to either add conditional formatting to multiple controls at once or a rule that I can set that will accomplish the same thing?
One requirement is that I can't use programming code to do this. I realize it would probably be far easier to do that way but that is a requirement given to me by my manager.
EDIT: Forgot to add this there are fields that still need to be edited when the other fields are read only.
One feature in InfoPath 2010 (can't remember if it was in 2007) that reduces the pain of this sort of repetitive work is the ability to copy-and-paste rules. With this you can create your read-only rule once and then just paste it onto each of the 30 controls that need it.
You could put it all in a section but your only option for sections is hide/show (not disable or read only). Otherwise you have to setup all the fields against that one dropdown. Huge pain but at least you only have to do it once.
An alternative, which is just about as much work, is to setup two views. One that is readonly and one that is normal. When the user changes the dropdown just flip the view. This method has a bunch of display nuances but does work.