Replacing "_o_Enable Button" doesn't work


I am a bit confused and I have missed something obvious probably.

In the form event “on selection change” in a listbox I have the following

$vtest:=((LB_Personal>0) & (arr_JobxSeqnr{LB_Personal}#""))
If ($vtest)
_o_ENABLE BUTTON(;“bsms@”)
End if

Everything works as expected. Fine.

So I want to get rid of the o… code and I substitute the if else end if with
OBJECT SET ENABLED(*;“bsms@”;$vtest)

And I find that this code does not give the intended result and does not work
the same as the if else end if code.

What am I missing?

Client Server

Best Regards

Magnus Torell

first, I don’t think there is any need to replace this particular o right now.

it is obsolete or deprecated, in the sense that there is a newer way of doing things,
but it is not a bad way of doing things, just dated.

in this instance, you can’t mix the old and new commands.
you either replace all instances or don’t replace any.

the same applies to replacing Self with OBJECT Get pointer, etc.

if the needed correction was to simply replace one command with another,
don’t you think 4D would do that automatically during the conversion process?

it is good to learn the new commands and use them in new development,
but there is no need to manually or mechanically replace old code just to look new.

Dear Miyako,

Thank you for the explanation. The problem I encountered was that
there were other places (on load and on clicked of a button)
where I had the old syntax unchanged and as you said: you can’t mix
the old and new syntax in this case. Fine. Thank you.

Regarding the o being OK to use I understand that the syntax works,
but I have understood that this conversion to o is a way for 4D to tell
developers: Ok it still works now, but it has been scheduled to disappear
eventually. As I am moving to v16 I am trying to prepare as best I can and
replacing o is one of the things on the list.

Best Regards

Magnus Torell

Actually the “o” prefix serves 2 purposes:

  1. Prevent developers from using obsolete commands. commands are excluded from clairvoyance/auto-complete>.

  2. Help developers identify obsolete commands in converted applications.

but the statement “Ok it still works now, but it has been scheduled to disappear eventually” is just not true.

The or removed features in…> page lists some commands as “deprecated”, others as “removed”.

Some commands are deprecated because they are at the mercy of external factors, such as the OS.

But as for scheduling commands to disappear, only a handful are given and all with a good reason.

For example…

Support for XSLT processing will be removed in future 4D releases.

We plan to remove support for these (QuickTime) specific APIs in the next release.

QuickDraw fonts are now deprecated…The _o_Font number and _o_Font name commands are kept in 4D v15 and higher for compatibility but will be removed in subsequent versions.

We plan to remove ASCII mode in future major versions.

These are the ones that you really need to focus on.

The docs even go as far as to say “we do not plan to remove support for subtables in the near future”.

Deprecated features that are not specifically mentioned with a plan to remove can be given a lower priority.

Hi Keisuke,

As Magnus I was also bitten by mixing ENABLE/DISABLE BUTTON and OBJECT SET ENABLED.
You cannot use both commands on the same button on the same form. It won’t work correctly (bug in 4D?).

That is why I chose to remove the old enable/disable commands when upgrading to v13 (if I remember correctly).

In the case of ENABLE/DISABLE BUTTON, IMHO there is no easy conversion just like a command name change. It also doesn’t make sense if you have “if(…) enable else disable end if” constructs. Those must be manually treated by the developer.

From personal experience I advise to replace ENABLE/DISABLE BUTTON in one swoop. First of all to be future proof for next 4D versions. The command will eventually disappear, I guess. But also to prevent the risk of mixing the old and new commands, which leads into unexpected results.
Imagine a new feature request from you customers needing some enabling of certain buttons somewhere in your code. But you did not look a the old part still using the old commands. Surprise… :oops:

Just my 2 eurocents.

I distinguish them as
use the variables and
use the objectname of the variables

no misbehaviour so far

Dear Koen, Ortwin and Keisuke,

I understand circumstances better now and also found that
Ortwins recommendation seems to work so far.
Use variables with old syntax and use object names when
you implement the Object Set Enabled command

Thanks everyone.

Best Regards


The scope of the old syntax is not only the variable, but the variable in all its instances in the process.

For example, suppose you have 2 forms, A and B, both have a button referenced as “bCancel” in variable name.
• the code opens form B from form A, in the same process.
• form B executes DISABLE BUTTON(bCancel)
• when closing form B, bCancel in form A is disabled
If this was wanted by the developer, replacing DISABLE BUTTON in form B by OBJECT set enabled will create a bug. That’s why it’s not possible to replace one command by the other.