Forum Replies Created
- August 5, 2010 at 3:22 pm in reply to: Using a table for data entry: use Key Is Pressed behavior to add a new row? #5394
lol i hear ya.August 5, 2010 at 3:02 pm in reply to: Using a table for data entry: use Key Is Pressed behavior to add a new row? #5392
I think this might be another good place to use separate input fields outside of the table to handle your inputting. You would have a button that adds those fields to a new row in the table and then sets the focus back to the first field. And with this method once you tab past the last field and focus is on the “input button”, your users would be able to hit enter and you could add the fields to the table, clear the fields, and return focus to the first field ready for the next row to be entered.
You shouldn’t need two separate commands for validation. I don’t see a link for your screenshot, but if I understand correctly you could do this with just one.
1) Set Table Rows: First Row
2) Checking the current row
3) Set Table: Next Row
4) Simple branch: Last Behavior Successful? If true go back to 2) if not exit the loop.
*cough* amen! *cough*
After your “Move to next row” you will need a simple branch that checks if the last behavior was successful dl.dropbox.com/u/883792/loop.png. If your loop is on the last row and you try to move to the next row that behavior will fail and this simple branch will catch that. It has to be done immediately after the “Move to next row”. Also just checking, prior to your “Move to next row” you are setting the current row of the table to the first correct?
I have a problem with this too. I think we need to have a datagrid/datalist control available for forms like the reports do.
You will need to undelete the old user account and transfer ownership of each form to the new user. To transfer ownership you will need to be logged in as the old user.July 27, 2010 at 9:17 pm in reply to: Populating a drop-down column in a table using a connection #5368
I was thinking about this today and got an idea for an alternate interface… Instead of making the fields editable within the table, maybe you could have a set of fields above the table and a button for adding the values to a table row. Then within each row on the table, add an edit button. When they click the edit button that would load the rows’ fields into the fields above, and maybe a save button. Yeah i know that sounds like a lot of extra overhead and yeah what really needs to happen is allowing us to dynamically populate fields in a table, but in the meantime this seemed like a good option.July 23, 2010 at 9:29 pm in reply to: Populating a drop-down column in a table using a connection #5361
I see your problem now, i just assumed the dropdown in a table would work the same as a dropdown outside of a table. This seems to be a lacking feature. I’m not able to accomplish what you are trying either, but I know in future forms i will need that same ability.July 23, 2010 at 4:59 pm in reply to: Populating a drop-down column in a table using a connection #5359
Make sure your target column is for all rows and not the current row. Also, not sure if you have already but try testing your connection action from the connection page and make sure you get results there.
In your return parameters, in procedure parameter column, you are using the RS1.xxx prefix to specify the result set correct?
I also get the error: 500 – Internal server error. There is a problem with the resource you are looking for, and it cannot be displayed.
I’m just going through the help documentation trying to build the sample project. When i get to the part about adding a service reference, that is not working and when i try to navigate to myserver/api/api.asmx?wsdl i am getting the 500 error.
Thanks, you guys are awesome. This is hands down my favorite software to use right now :). Takes RAD to new heights.
Lol I had hoped you wouldn’t suggest that. That was going to be my fall back if “unspecified” couldn’t be added to the list of roles. For now that will work, but would getting control of unspecified be possible in any near future releases?
Sorry, I originally started this post and wasn’t getting an immediate response so i submitted a ticket later on. I see your point on only one person being able to start a form so rights at the default stage shouldn’t matter for the rest of the roles, but each stage in our forms has a “reject” path that sends the form to the previous stage. So if a stage 2 user opens a form at stage 2 through an email link, and decides the submitter has forgotten to attach something or (and this is just me thinking maliciously) maybe they want to change something in the form, and they have figured out that their role has unlimited rights to change a form at the default stage. They could resubmit it if they reject it back to the default stage. They could open the link they received previously after they have rejected the form back to the submitter and before the submitter has gotten a chance to get into the form, make any changes, and resubmit the form. Now we have put things in place like a signature line that gets filled with the users name and date that clicks the submit button, and I would like to think that this is something that would be noticed fairly quickly. However, being a financial institution, it’s not something we feel comfortable leaving to chance, and seems like if we could just control a field state for “unspecified” and treat it like an individual role, that would solve our problem.
Thats what I have been attemping –
“Use the ‘Default Stage/All Roles’ combination to control the state of objects for a user starting a form.”
But it is not working. Lets say I have a form with 4 stages and 4 roles (A Submitter and 3 approvers). If I have fields that only the submitter should be able to change at the Submitter(default) stage, I only want the submitter to be able to make changes to the field at the submitter stage. However, if I go into a fields edit state window, and set the field to be read only for all roles at that default stage except the submitter, how can i make the field editable by the starter, since the default role is “unspecified”? The only time now that I have been able to get a field in the normal state for unspecified is if a “majority” of the roles see the field in the normal state at a given stage. I showed this to CJ earlier this week. What you are saying makes sense and seemed to work fine in 1.16, but since the upgrade I have not been able to make a field normal for both my submitter role and the default unspecified role at the default stage.