This would save loads of time when testing a specfic section which is far down the form and the form is configured in a Wizard View.
I just wondered whether there is a querystring parameter or xpath setting to put in xforms-inspector which will save us endless clicks on the Next button! So far the best way I have found is to disable the Wizard View so that the form shows vertically.
This isn't currently supported, but it sounds like a worthwhile feature to have, and I've created an RFE for this feature.
I don't understand why you have to click next all the time, you should be able to just click on the section name in the table of contents.
Related
I've had some testers reporting an intermittent issue on a search page that contains a list.
They say when they have been on the page and navigate to a sub page then return that the list is sometimes scrolled all the way to the bottom of the screen.
I've disabled tensile drag on the list, but I wanted to know if there was any other work-around for this issue?
This has nothing to do with tensile drag. When you navigate from one form to another in the old GUI builder the form is re-created from scratch and re-positioned based on the data.
We try to select the previously selected item but if something in the list changed this might trigger issues.
You can override restoreComponentState in the state machine with a blank implementation to see that this is the cause of this behavior. Assuming that it is you can create a special case for the list instance.
I have created a form with 6 sections and configured Cancel, Next, Prev and Submit buttons in properties-local.xml.
It is usually not advisable to allow the end-user to submit the form until they have at least reached the final section. The only way I can see that this may be possible is to use buttons within the form and by checking which section is currently in focus.
I notice that this has been fixed for Orbeon 2016.1 (see Is it possible in orben to hide or disable the "send" button until a form is finished?), but just wondered whether there is a workaround for Orbeon v4.10?
With 2016.1, this requires the following conditions:
Use of the oxf.fr.detail.buttons.inner property.
Use the wizard's validated mode.
The documentation on this was missing. I have just added it. I hope this helps!
I am a newbie, i am trying to create a view where every time i click on add more link next to a Textbox, another text box appears. How do i do that? I searched the same question on this site but i could not find a solution.
You'll have to create an array (string[] Smth)in your model. Then you have to make your "add more" link to submit your form to controller action that will add another element to this array and roundtrip back to view.
You may take a look at the following article which illustrates how you could handle dynamic rows.
I'd like to create a content box with two tabs. Each tab is associated with a table which contain server-side data. My thought right now is just to load the page with 10 rows worth of data for each table and hide/display each table respectively to begin.
I was then going to toggle display of the tabbed content based on either click events on the tabs OR GET parameters relating to which tabbed content is being acted on (through pagination, for example).
Should I just handle this with UI tabs or is toggling display reasonable in this case? Since the user can update their data, I assume that caching via the tab UI isn't helpful in this case.
Thanks,
Brendan
From what I understood, I don't think its going to be overkill. If you are worried about performance, ten rows for 2 tables is just 20, which is not much. Paginating will also get 10 more rows for each 'click' so it's still good there.
Do use tab activation through click events, but also use GET parameters to know in which page the user currently is, from which tab.
Regarding caching data that you know will change, it might be unnecessary (see my 1st paragraph). Caching can sometimes become unwieldy, so don't add an uneccesary layer of complexity.
As someone who suggests simplicity above all else, I'd discard the whole 'tab loading' thing but leaving the tabs per se (i.e. the interface elements that will be clicked) and when the user clicks each tab, it takes to another page with the tabs too, old-fashioned style.
I have a tPageControl on a form, and have made a nice 'welcome page' as a new ttabsheet at design time for the user to start off with. However, if the user closes this tab, I would like the option to bring it back, as it was in originally (much like the welcome page in the Delphi IDE). This seems like a simple problem...
When the tab closes, the original sheet is freed and set nil. I tried creating the sheet again by name (e.g. tabsheet1 := ttabsheet.create) and assigning it to the pagecontrol, but none of the original components from the sheet are there anymore...
I know designing the welcome page as a separate form, creating it when I need it and slapping it into a new tabsheet would work... but I was just wondering if there was a way to do it with the design time tabsheet.
Thanks all!
Rusty
As Serg mentioned, you can just set the tabsheet's TabVisible property to false when you want to hide the page. The page control will switch to the next tab if it needs to, the tab will disappear, and the user won't be able to switch back to it until you change TabVisible back.
Re-creating the design-time tab sheet will be quite a challenge because all the information describing its layout is embedded in the DFM resource for your form. It's not like there a separate resource for each tab, so you'd need to read the resource, extract the portion relevant to the tab, and then get ReadComponent to build a new instance; nothing in Delphi is designed to make that very easy, so you should consider other options.
The easiest solution would probably be to design your welcome page on a frame; I've found frames to be a little more cooperative than full-fledged forms when it comes to re-parenting them.
Another option is to create the entire tab in code. GExperts has a tool to make that pretty easy. Select the tab sheet, and then choose DExperts's "components to code" command. That places some code on the clipboard, and you can paste it into a function in your program. The code will contain everything required to re-create the selected components in code instead of building them from the DFM resource. Then, you can use that function to not only re-create the tab after it's been closed, but to create the tab in the first place. That way, you can be assured that you're creating the same thing both times.
The reason your attempt at re-creating the tab didn't work is that the name of the variable used to hold a reference to the form doesn't really define anything. All you did was create a brand new TTabSheet. The fact that you stored a reference to it in the same variable that used to hold a reference to the old tab is irrelevant. (But please feel free to give that variable a more meaningful name; all "TabSheet1" says is that it's the first tab you put on your form, way back when you first started working on this project.)
Rob's right about what's going on, and about using frames to fix it. Bit if you want a simpler solution, you could try just making the tab invisible whan the user closes it, instead of freeing it.
Thank you all for your comments and suggestions. A couple notes :
I tried the GEExperts option (pretty nice, I havent used this one before!) : however, it did not preserve many design time settings (font size and color for example)...also there were components with glyphs that didnt get saved....
Changing the visibility of the tabsheet doesnt seem to work either; the pagecontrol doesn't seem to know what to display, even after calling .Refresh ...it shows whatever is underneath your window.
Anyhow, I might investigate the frames option, but likely will just move the components to a new form and call it when needed...
Thanks again!