Is it possible to create customer Properties for a given OI10 form?

I'm working on a simple (unbound) window form and need to save information unique to each edit field or combo box which is later utilized during form initialization via the create event as well as call Basic + stored procedures after clicking an Add, Update, and Delete button. The current properties are not appropriate to store these values other than possibly the Misc property.

My preference is to assign the custom properties during form design time and not via the forms create event.

A simple scenario: A form displays data collected from executing a SQL stored procedure. After receiving the result-set (and assigning it to a variable named ResultSet) from the SQL Server, the data is used to initialize an associated edit field. Typically the SQL Result set includes two rows. ResultSet<1> contains a MV list of column headings or names and ResultSet<2> contains the data associated to the column headings. My goal is to devise a means to link the resultset<2> data to the form's edit fields via the resultset<1> column headings. Assigning the SQL column heading name into a property during design time defines the link therefore, during run-time the resultset<2> data can be assigned to the correct edit field's TEXT property. A simple approach is assigning the Edit Field's name to match the resultset<1> column heading/name. But, this doesn't work well with combo boxes. Each combo box contains a list of options also initialized via a different SQL Stored Procedure and assigned to an OptionsResults variable consisting of multiple rows and typically two columns. Therefore the OptionsResults<1,1> is the record id to the SQL Table where the options were retrieved and OptionsResults<1,2> is the description. Then OptionsResults<2 through many> contains the valid option choices. During the form's create event, the various comboBoxes' list is initialized and are constructed as record id - (hyphen or other delimiter) description. Therefore for a list of buyers, a custom property would contain a value like BuyerID - BuyerName. Then, when the Add button is clicked, the routine can easily extract the BuyerID portion from the Combo TEXT property via a simple FIELD(…) statement.

If custom properties is unavailable, do other options exist?

Mike Daniel

480-699-0212

Is there a reason you aren't using the SQL BFS?

Unlike AREV prompt registers you can't assign custom properties before runtime, but you ARE aware that you can create as many custom properties as you like by prefixing the property name with @?

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

What is SQL BFS?

Yes, the @ variables are promising but unfortunately are restricted to run-time. Perhaps utilizing the MISC property during development time and extracting the MISC information and updating the @variables during run-time could be a work-around.

I've inherited several (probably well over 50) ASP applications created in MS VS.Net 2008 or 2012 utilizing 2008 Crystal Reports and several versions of DevExpress both of which are MS Visual Studio add-ons. Everything is out dated!! And those web applications are experiencing compatibility problems running on newer IIS servers and the company wants to decommission the 2012 SQL Server and 2012 MS Servers with IIS and implement more recent SQL server and Windows server versions. Nearly all of the ASP applications utilize SQL Stored Procedures for inquiry/selects, options lists, updates, and deletes. Therefore, I hope to leverage those store procedures and create OI10 forms simulating the existing ASPs. Most of the stored procedures include multiple table joins. Basic + routines that execute the stored procedures and retrieving result sets already exist. Next is to create a set of Basic + routines to populate the OI10 Forms as well as retrieve information from the OI10 form to update the SQL Tables via the SQL Stored procedures and these same Basic + routines can be used somewhat generically with all OI10 forms replacing the ASP forms. The goal is "pseudo linking" the various OI10 entry fields to the SQL Stored procedure for the different SQL requests (e.g. SELECT, UPDATE, and DELETE) whereas the reference name in the form is associated to the same variable or field name in the SQL Stored Procedure.

One of OI10 strengths is updates and patches… It affects the entire system and therefore all applications simultaneously. Where-as each VS.Net application needs updating individually. This applies to each add-on update along with VS updates and as frequently updates occur in the .NET environment (including add-ons), considerable time is needed to keep all applications utilizing the same versions.

Mike Daniel

480-699-0212

Mike, consider making a table whose rows contain the text that you want used during the CREATE event of the form. Be creative with the KEY value.

Then, you can make a form that you use to edit those text values, or just the EDITOR.

Thus, no need to store values in the OI form like Arev did.

Dave

Hmm… Okay, I will.

Thanks for the tip Dave,

Mike

I thought I had answered your question about the SQL BFS but on checking it seems I didn’t. Basically using this you can use OpenInsight forms to read and write directly to SQL tables as though they were Linear Hash. There is a section in OI10 help about it

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

Post removed by author

FYI,

The upcoming v10.0.8 release has support in the Form Designer for CustomProperties, which become user-defined "@" properties at runtime. For each object you can define a list of property names and their initial values.

Regards

Carl Pates

FYI,

The upcoming v10.0.8 release has support in the Form Designer for CustomProperties, which become user-defined "@" properties at runtime. For each object you can define a list of property names and their initial values.

See here for more details:

Adding Custom Properties in the Form Designer

Regards

Carl Pates

View this thread on the Works forum...