When you add a symbolic item to a form

Should the default be readonly?

as you can't change the details and client is complaining about having to enter over it

Now changing all my newly created/arev imported forms..

Gerry

When you add a symbolic item to a form

Should the default be readonly?

Yes. This has always been the default.

Don Bakke

SRP Computer Solutions, Inc.

Don,

you mean it should be?

as its not in OI10 as I just added one to test.

Also when any prompt is readonly you cant use QBF on it. There is a way around it but..

Gerry

Don,

you mean it should be?

as its not in OI10 as I just added one to test.

Also when any prompt is readonly you cant use QBF on it. There is a way around it but..

Gerry

Allways 'Disabled' for me (ReadOnly not ticked) OI9

OI10 Enabled=False ; ReadOnly=False

Don,

you mean it should be?

as its not in OI10 as I just added one to test.

Also when any prompt is readonly you cant use QBF on it. There is a way around it but..

Gerry

Allways 'Disabled' for me (ReadOnly not ticked) OI9

OI10 Enabled=False ; ReadOnly=False

Both OI9 & OI10 you need to set it yourself.

I know how to do it..

BUT

All I am saying is I shouldn't have to.

If you are a new developer using OI10 for the first time

You will have no idea that you need to set this manually.

Just a suggestion..

Gerry

Don,

you mean it should be?

as its not in OI10 as I just added one to test.

Also when any prompt is readonly you cant use QBF on it. There is a way around it but..

Gerry

Gerry - My apologies. I didn't consider you were making a distinction between disabled and readonly. Since a disabled control is also readonly, I was answering from that perspective. As you and Barry have already discussed and agreed upon, symbolic fields always produce a disabled control at runtime. To change the normal behavior at this point would introduce unexpected behavior for many apps. I suppose a way to solve this problem would be to introduce a new property that would tell OI to override the disabled style regardless if the datafield is symbolic or not.

Don Bakke

SRP Computer Solutions, Inc.

Hi Don,

You are correct, it should be disabled and readonly

but its NOT

If you add a new prompt and its a symbolic it is enabled and readable

so the user can type anything in there, doesn't save anything but shows like you can

So you have to manually change the settings to disabled (or readonly also works)

for it to be skipped and not show as open.

That is my issue..

I think all symbolics regardless of the settings should be automatically disabled

I can put in my create event to check and change it but it should be an OI function..

Gerry

Hi Gerry

<I think all symbolics regardless of the settings should be automatically disabled>

I'm not sure that I agree with - that is I agree that on a data entry form we may want to auto-disable the symbolic (we can do that anyway with about two clicks) BUT what about the new (pending?) QBF search feature and the select filter I created for sort/selecting records to then load into a data form? It's really great to now be able to create sort and select lists without being messed up by formats etc- and the data entry form can thus be a great feed into ad hoc reports.

Richard

In v9 and earlier:

Edit controls: Symbolics bound to edit controls are "soft disabled", i.e. they _look_ like they are enabled by you can't interact with them (basically all mouse and keyboard interaction is blocked). Rev created this non-standard state specifically for symbolics back in the days of OI v2. This is why we have a hard disabled and soft disabled setting for edit controls. TBH I don't know why this was done - maybe they didn't like the way it looked? They also never supported the Edit "ReadOnly" state which, IMHO would have been a better choice.

Edit Table columns are flagged as "protected". Again, they look "normal" but you can't edit their contents.

All other controls are disabled as per the Windows standard.

v10 _should_ have followed this pattern and does not - this is a bug that we will rectify for the next release.

QBF:

The classic QBFINIT process sets all controls bound to a the Primary table to ENABLED - TRUE$ (except for edit table columns, which have the column protected flag removed). It does not attempt to touch the ReadOnly property. Also note that check box controls are never included in QBF queries and are always disabled.

QBF in the next release has had an overhaul, including:

Edit controls have their READONLY property set to FALSE$ and well as being ENABLED,

Edit table columns have an EDITMODE property set to ENABLED as well as having their SKIPOVER property removed.

Carl Pates

Just an idea for the next QBF implementation.

With regard to QBF our implementation starts by using the QBFINIT event for the form, but after that it we added our own code and custom toolbar to handle things like loading and saving results, pasting result (keys), showing all keys via a popup etc.

We also supported using checkboxes and radio group controls as part of a search, as we didn't want to eliminate them as an option, but similarly we didn't want them included unless the customer actually wanted to.

Using UTILITY → OBJECTLIST commands to gather the relevant controls, for checkboxes these needed to be destroyed and recreated as 3-stage checkboxes and set to null (which got reverted following the query/results being gathered). For radio group and combobox controls, we set the selected value to null.

Hope this is useful, happy to supply code if you like.

Post removed by author

The QBF interface stumbles when you have controls such as radio buttons, combo boxes or ole controls, as well as on readonly vs disabled, etc. OI10 Includes a function named RTI_QUERYGRID_OIWIN, which in turn calls a function named RTI_QUERYGRID. These programs have a functionality similar to what James describes. The goal is to provide an interface which mimics the excel query grid and the OI indexlookup interface.

In your window use a quickevent to call a stored procedure, with a target of RTI_QUERYGRID_OIWIN

RTI_QUERYGRID will scrape all the data bound controls from the form using OBJECTLIST, then, call RTI_QUERYGRID.

You can call RTI_QUERYGRID directly from a button too. It is intended to be a replacement for INDEXLOOKUP. RTI_QUERYGRID builds an RLIST query rather than a BTREE.EXTRACT, so you can use it to query non-indexed columns too.

function RTI_QUERYGRID(ownerwindow, table, SearchFields, displayedfields, mode, popupname, by_clause)

     /******************************************************************************

     *

     * Variation of INDEXLOOKUP which works on non-indexed columns too, supports sorting

     *

     * ownerwindow = parent window

     * table = data table

     * searchInfo = fields for the lookup, vm/svm delimited structure colname [ svm label svm conv svm operators svm optionlist]

     *     colname = name of search column, required

     *     heading = label , optional

     *     conve   = output conversion, optional

     *     operators =  svm delimited list of comparison operators, optional

     *

     * displayedfields = fields to display in popup, optional, defaults to null. NOTE: leave null to return all keys from search

     * mode  =single / multi, optional, defaults to single, only aplies when you supply popup or dispkayfields

     * popupname = predefined popup to use in line of displayfields, optional, defaults to null

     * by_clause = sort cluase, e.g BY LNAME BY FNAME, optional, defaults to null

     *

I think all symbolics regardless of the settings should be automatically disabled

Not sure I'm understanding this thread, but I can think of several use cases where you would still want a read-only editfield to be enabled. Even if you can't change its contents, a control that can gain focus allows:

- A Zoom function to be applied where the contents displayed doesn't fit within the available area

- Text selection for a Copy and Paste into some other UI component.

- A generic 'soft-key' function that can perform some action using that data in context. Eg, opening up another window for more information.

Cheers, M@

Vernon Systems

Hi M@,

Just to clarify - basically the problem is a bug in v10 that I fixed today - namely that adding a control bound to a symbolic is not disabling the control (or "soft-disabling" it for edit controls). This is the default behavior of v9, and it's also (now) the default behaviour of v10 controls, which was the intention all along.

QBF will enable these symbolic-bound controls when the form is in query mode, and will reset them when the query is executed, again. as per v9.

Having said that - I'm with you - I'd actually prefer symbolic-bound controls to be read-only so that they can be interacted with - the problem we have is that any time we slightly change anything it will break someone's app somewhere. I 100% guarantee it :) Tbh I've never bee na fan of "soft-disabled" because you have a control masquerading as something it is not - it looks enabled but …

So, there's nothing in this thread that will break anyone's existing app, but if switching symbolics to ReadOnly were to happen it would have to be via a property switch that was off by default. E.g. we did this for the new FORMSTATECHANGED event - it will only fire if you set the new "AllowFormStateEvents" property to True.

Cheers

C

Carl Pates

Thanks Carl..

Gerry

Hi Carl,

Ah yes, you're right - I see we've got some work-arounds in place ;). But not too many - so an opt-in property switch to allow enabled + readOnly for symbolics might be useful?

Cheers, M@

Vernon Systems

…so an opt-in property switch to allow enabled + readOnly for symbolics might be useful?Vernon Systems

I think that is essentially what I proposed earlier in this thread:

I suppose a way to solve this problem would be to introduce a new property that would tell OI to override the disabled style regardless if the datafield is symbolic or not.

Don Bakke

SRP Computer Solutions, Inc.

View this thread on the Works forum...