Филиппcompute object может быть только 2х типов - string или numeric
можно узнать откуда такое утверждение/ограничение?

смотрим Help: Using DataWindow painter and InfoMaker functions
где явно указано, что:

Return values for functions and expressions
DataWindow painter and InfoMaker expressions can return the following data types:

Double

String

DateTime

Time

Within an expression, a function can return other data types (such as boolean, date, or integer) but the final value of an expression is converted to one of the four data types.


проверяем:
создадим DataWindow

добавим compute object с именем cf_today и выражением today()

добавим другой compute object с выражением string(date( cf_today ), 'YYYYMMDD') + ' / ' + string(time( cf_today ), 'hh:mm:ss')

откроем просмотр DW и видим что:
в первом compute object результат: 23.03.2004 13:06:57:08
во втором compute object результат: 20040323 / 13:06:57

следовательно тип возвращаемого значения compute object с именем cf_today является DateTime.

PS
Добавить compute object в существующий DW/DS можно с помощью dwcontrol.Modify ( modstring ) и modstring типа: "create compute(...)"

а потом уже можно получить его тип с помощью обычного свойства ColType

удалить с помощью: "destroy objectname"


===
Гришин Дмитрий

Филипп compute object имеет property ColType. Так вот если посмотреть в тот Help, то там ясно написано, что для compute object ColType возвращает string или numeric.

Филипп, неужели трудно попробовать? :) всего три действия:

Создай external DW,

в нем создай compute object c именем cf_today и expression равным today()

создай второй compute object с expression как describe( "cf_today.ColType" )

и что ты увидишь в результате второго compute objecta ? :)) Думаешь string или numeric?
Хоть убей, но у меня в результате datetime :)

Или по твоему cf_today это не compute object? и describe( "cf_today.ColType" ) возвращает не его property?

PS
если не сложно, кинь ссылочку на тот Help, где
Филиппясно написано, что для compute object ColType возвращает string или numeric.
===
Гришин Дмитрий

ФилиппО да, есть некоторые аномалии с DateTime, причём интересно, что если expression вот такой - Date(Today()), то ругаться не будет, но всё равно вернёт DateTime. А если Time(Today()), то вернёт Time.
Во всех остальных случаях вернёт или string или number.
Никаких аномалий нет - поведение ожидаемое , согласно:
HelpWithin an expression, a function can return other data types (such as boolean, date, or integer) but the final value of an expression is converted to one of the four data types.

А на счет чем лучше пользоваться Describe(Evaluate... или подключать на лету compute object - решать разработчику. Главное что бы был выбор.

Могу сказать, что в моем проекте использование подключаемых compute object'ов до начала обработки DS и использование GetItemxxx(...) в процессе обработки позволило повысить производительность на 50%. И это только на тестовом примере, в котором DS состоит из 75 строк + 40 определяемых пользователем вычислимых полей. Что в общем-то объяснимо - быстрее получить готовое значение, чем постоянно его вычислять.

Мысли вслухнебольшое отступление
немного странно, что в PFC (до 6.5.1, дальше не смотрел ) используют постоянный перерасчет expression для compute object'а в функциях of_GetItemxxx(...)
Единственное объяснение этого - что Sybase не гарантирует, что в данный момент в этом compute object'e находится правильный результат, и расчитывает его заново, на всякий случай...
Неужели в compute object'е может храниться неактуальное значение? Может такое быть?

Согласен с тем, что Филипппо большей части compute objectы в которых участвуют Date/Time чаще всего используют форматирование внутри выражения и так или иначе превращаются в stringи, но все-таки, иногда приходится работать с вычислимыми полями с возвращамыми значениями не только string & numeric, хотя бы для использования результата одного compute в другом без лишних cast'ов и преобразований.

===
Гришин Дмитрий

Здесь ключевые слова "определяемых пользователем"
а пользователь их может определить сколько его душе угодно, и нельзя его в этом ограничивать...

Локшин МаркДа много чего можно делать.
Это точно.

2 Локшин Марк
Локшин Марка о GetDetailHeight PowerSoft/Sybase почему-то (что вообще-то в их стиле :) ) забыл. evaluate только и спасает.
разве rowheight() не спасет?

===
Гришин Дмитрий

Локшин МаркНу, а вычислять ее вы как собираетесь?

HelpThis expression for a computed field in the detail band displays the height of each row:
RowHeight()

dw.getItemNumber(dw.GetRow(), <compute object name> )

т.е. так же как и получаем значение любой другой колонки с использованием функций getItem

===
Гришин Дмитрий

авторА если такого <compute object name> нет? Создавать его? Ну просто замечательно.
Или вы про то, что принципиально без evaluate можно?

Все зависит от того где вы и зачем используете эквивалент своей GetDetailHeight.

Можно создать на этапе разработки, можно добавить перед обработкой, можно не создавать и рассчитывать постоянно через evaluate, когда необходимо, а можно и вообще не создавать, если определение высоты строки используется для форматирования высоты других объектов в строке...

Так зачем вам высота строки?

===
Гришин Дмитрий