FORM中参数parameter.G_query_find的作用及客户化菜单设置

FORM中参数parameter.G_query_find的作用及客户化菜单设置
  一、FORM中 手电筒的后台流程

在我们的系统中手电筒的运用是很平常的事了，他在FROM中的实现想必大家也都很熟悉了，然而在代码设计中有一个参数（:parameter.G_query_find）很是让人朦胧，记得刚开始做手电筒时也只是机械的参考标准开发文档来做的。做完了虽然是实现了功能但不知其所以然。在前几天开发的FORM中做手电筒时，测试了下发现参数:parameter.G_query_find的作用是决定查询范围的一个开关。当:parameter.G_query_find:= 'TRUE'时，系统会根据我们在触发器（pre-query）中所定义的条件去查询。当:parameter.G_query_find:= 'FALSE'时，系统就会跳过查询条件，进而查询出全部记录。理解这个其实最主要的是明白手电筒使用过程中的触发器顺序，掌握了这点，也就明白了这个参数的作用。

下面我就描述下测试的结果：

 

操作	触发器	相关代码	备注
点击手电筒	QYERY_FIND	app_find.query_find('MAIN_WIN',QF_WIN', 'QUERY_FIND');	查找窗口弹出
点击查找按钮	WHEN-BUTTON-PRCESS	:parameter.G_query_find := 'TRUE'; ① app_find.find('demand_summ'); ② :parameter.G_query_find := 'FALSE'; ③

主要的隐藏点就在于WHEN-BUTTON-PRCESS 触发器中的代码从②?>③的过程中他会调用pre-query触发器（其实还有其他一些触发器，这里我们主要讨论有关手电筒的这几个触发器）。
这下我们就比较清楚了，当点了查找按钮，正如①所示参数parameter.G_query_find 被设置为'TRUE'，接着调用pre-query，在触发器pre-query中IF的满足条件是parameter.G_query_find='TRUE'，所以系统会按查询条件进行查询结果。总的流程写到一块如下：

--点击手电筒(QYERY_FIND)

app_find.query_find('MAIN_WIN','QF_WIN','QUERY_FIND');

--查找窗口出弹出输入条件点查找按钮(WHEN-BUTTON-PRCESS)

:parameter.G_query_find := 'TRUE';

---app_find.find();--开始

when-create-record

---pre-query开始

if :parameter.G_query_find ='TRUE'
then

app_find.query_range(:query_find.demand_number_from,

:query_find.demand_number_to,

'demand_summ.demand_number');

app_find.query_range(:query_find.apply_date_from,

:query_find.apply_date_to,

'demand_summ.apply_date');

copy(:query_find.status_description,'demand_summ.status');

:parameter.G_query_find:='FALSE';

end
if;

---pre-query结束

post-query

:parameter.G_query_find := 'FALSE';

when-new-recocrd-instance
二、客户化菜单设置及右键1.
Customizing Right?Mouse Menus (Popup Menus)

系统中默认右键菜单如下：

Cut

Copy

Paste

??????

Folder

??????

Help

我们可以客户化添加一些菜单项，Oracle 只支持10个，客户化添加的菜单一般位于

Folder和Help之间，并且可以用分割线（??????）。例如下例：

Cut

Copy

Paste

????????????

Folder

????????????

First Entry

Second Entry

????????????

Third Entry

????????????

Help

 

现在我们用一个简单的例子演示一次客户化右键菜单：

（假设需求是：当焦点进入采购订单编号项中时，在右键菜单中增加一个’Approve’项，至于具体点击了菜单项Approve后，系统要完成什么逻辑可由自己添加代码，这里我们为测试就只输出一点测试信息）

具体分2步骤：

1.
在采购订单编号项上添加一个Item级的Trigger（PRE?POPUP?MENU）代码内容如下：

app_popup.instantiate('POPUP1', 'Approve');

注意：Trigger 的执行层应设置为After,以确保Form级的同名Trigger先执行。

2.
继续在采购订单编号项上添加一个Item级的用户自定义Trigger（POPUP1）

（具体代码可由实际需求来定这里仅测试）：

fnd_message.debug('Approve!');

2、Application?Specific Entries: Special Menus

对于系统的标准菜单我们也可以进行客户化，他最多支持45并且我们还可以在Toobar上增加新的图标与之对应。

这里我们还是举个简单例子，需求假设是当焦点进入Header块时，标准菜单中就会启用我们新添加的菜单项（Book Order）。

具体步骤如下：

1. 在Form 级的触发器 PRE?FORM 中添加如下代码:

app_special.instantiate('SPECIAL1', 'Book Order', 'bkord');

2. 添加一个Form 级的触发器PRE?BLOCK
代码如下：

app_special.enable('SPECIAL1',PROPERTY_OFF);

3. 在Header 块中添加一个Block级的触发器PRE-BLOCK 代码如下：

app_special.enable('SPECIAL1',PROPERTY_ON);

4. 继续在Header 块中添加一个Block级的用户自定义触发器PRE-SPECIAL1

（具体代码可由实际需求来定这里仅测试）：

fnd_message.debug(' Book Order!');

附注:对于45个菜单项的设置简单描述下： 45个项会分配进3个特殊菜单中（工具、报表、活动）

工具： SPECIAL1---SPECIAL15

报表： SPECIAL16---SPECIAL30

活动： SPECIAL31---SPECIAL45