Hi All

I have a form, and a dialog called by the form and an omnievent on the main form. I am trying to step through all the processes to make sure it doesn't eat anything on the way. I also have a subroutine which I call to do some of the array processing.

My current problem is the debugger wont "step into" the omnievent.

I return to the main form (button click event) from the dialog then update some of the main form data with the new data, then I run the omnievent to refresh the display edit tables on the main form. I am using send event to call the omnievent but the send event won't run the debug.

Code on click after return from dialog

message=DISPLAY_PAGE' ;* process to refresh and edit table "page"

action=LAST_PAGE' ;* from the souce data which I just updated

* figure out which is the last page and put that in the edit table

void=SEND_EVENT(@WINDOW, 'OMNIEVENT', message, action)

I really need to step through the omnievent code at this point because one of the fields on the table is not being updated correctly but the debugger steps straight over the send_event call even when I click the step into icon.

Does anyone know why this happens and how I can fix it?

I have "debug"s in the omnievent and the subroutine that it calls as well as the click event on the button. Is this too many or not enough?

Is there some way I can run the omnievent code without using send event? Can I use the subroutine to update the window controls directly? How do I make sure it updates the correct window?

Scott, LMS

Janet,

First, there can never be "too many" debugs in your code. As long as you remember to remove them before deploying the system

Second, OpenInsight will not step into code that you call via the Send_Event function. If you have a debug in the event you are calling this way then ordinarily it will bring up the debugger for you. Stepping into code only works when one routine (or event) calls another routine (but not another event.) Of course, you need to have source and the debug records in order to debug your code thoroughly.

Third, avoid using event scripts as much as possible. I used to use OMNIEVENT for a while and resisted using stored procedures. Unfortunately this has more problems than benefits - debugging your code being one of them.

Fourth, from the description of your post it appears that the click event code is being executed from the dialog box's button. Is this correct? If so, then one of your problems is that you are using @WINDOW in the Send_Event() call. @WINDOW is always set to the window to which your code/event belongs to. If this button is on the dialog box then @WINDOW is also set to the dialog box and you are attempting to execute the OMNIEVENT of the dialog box rather than the main form. Hence, your OMNIEVENT is not getting called at all.

If this is not the case then I will need more information. It is not very clear what control is calling the code with the Send_Event.

[email protected]

SRP Computer Solutions, Inc.

Hi Don

Thanks for that.

No the main form has a button, when you click the button you get the dialog, when the dialog returns to the main form button click event, the next thing is to call the send event…

I had a debug (or three) in the omnievent but it didn't stop. I managed to find out where the problem was by using a message box to display the problem variables. Turned out my problem was I was trying to use the record which hadn't yet been updated to tell me what the lookup descriptions were. I changed it to lookup the lookup table directly instead of using calculated fields with values that were not there yet. Hmm that nearly made sense.

So how do I translate this stuff into event script free code?

Can my stdproc subroutine access all the controls directly instead of me using the event code to grab the controls I need as parameters to send to the stdproc subroutine? Of course I use the event to put all the returned parameters back on the form too. How do I make sure the window is the right one, how do I catch the event trigger?

I know Oystein wrote something about commuter events and promoted events but I still couldn't see how I could make that run without something in the event which said "run commuter proc". If I pass @WINDOW to the commuter proc in a parameter called this_window, will this_window : '.MYCONTROL'-]TEXT get me the value of MYCONTROL? I am beginning to feel I'd like to pull the whole application inside out because those that "designed" (it wasn't I'm sure) and built it, had no idea about the most effective way of building OI apps. I am sure I still don't know.

I am going to write something that will list me all the controls on a form, any table bindings they might have, and then for each event, all the code in the event.

I will experiment with my stdproc to see if I can get it to do the control updating directly.

Scott.

Hi All

I feel a bit small now. The following is the beginnings of my form documenter using as little event code as I can manage. Is a "promoted" event different to this? Is this the same as a commuter event?

———form FORM_DETAILS_RPT —————————-

Run button (called BTN_RUN) click event (on FORM called FORM_DETAILS_RPT)

declare subroutine FORM_DETAILS_RPT

* MAIN:

FORM_DETAILS_RPT(CtrlEntId, @WINDOW, err_dets)

RETURN 0

———stdproc FORM_DETAILS_RPT—————————

Compile Function FORM_DETAILS_RPT( CtrlEntID, this_window, error_msg)

* Main

• CtrlEntID is "FORM_DETAILS_RPT.BTN_RUN"

if unassigned(this_window) then 

	this_window='

	goto EXIT

end

mywindow=this_window		;* my window is "FORM_DETAILS_RPT"

• Values from the form can be grabbed with the following:

• given that the control names exist

• .TBL_FORMS-]LIST

myforms=GET_PROPERTY(this_window : ".TBL_FORMS", "LIST")

• .EXPORT_PATH-]TEXT

mydir=GET_PROPERTY(this_window : ".EXPORT_PATH", "TEXT")

• .TXT_FILE_NAME-]TEXT

myfile=GET_PROPERTY(this_window : ".TXT_FILE_NAME", "TEXT")

Return 0

Scott,

I'm not certain how much you know. I may explain a bit too much here, but bear over with me.

"Event scrift free" just means you use quickevents instead of scripted events (also called user events).

With a user event you have the program code directly in the event, sort of. With a quickevent you put almost the same code in a stored procedure and let the quickevent call that procedure.

Quickevents can do many different things - Start a window, Execute a popup, Display a message, etc. But what we're interested in here is the Execute a procedure option.

There are a few differences between user events and quickevents. E.g, the "dot arrow" shorthand for getting and setting properties is reserved for user events. In quickevents you have to use Get_Property and Set_Property.

Also user events run earlier than quickevents, and sometimes you must use a user event to achieve what you want. But not often.

Further: In a user event there is a fixed set of parameters (CtrlEntId, etc), depending on which event it is. With quickevents you set your own parameters (in the QuickEvent dialog). You don't always need parameters, but they're often useful. E.g, the procedures you run from quickevents often need some way to find out who runs them (which control); you don't want to write specific procedures for each and every window/control/event you've got. And one way to tell a quickevent procedure who called it is to use parameters.

The quickevent parameters can be fixed values (numbers or quoted strings), or some special variables I'm going to tell you about shortly. But here is first how you can do the above (tell the procedure who called it) with constants: Let the stored procedure have a parameter for the current control (call the parameter CtrlEntId if you like). In the Parameters field of the quickevent put the name of the control - e.g, 'MYWINDOW.EDITLINE_1'.

But as I said - in addition to constants there also are a few special variables you can use. E.g, in the above example you can achive what you want by using the '@SELF' variable as the quickevent parameter. '@SELF' always contains the name (id) of the control that owns the quickevent. (Note! Even if '@SELF' is sort of a variable you still need the quotes!)

Another such variable is '@WINDOW', but that's not so useful because your stored procedure can always check the system variable @Window. Both contain the name (id) of the current window.

Quickevents can get and set values from controls, just like user events.

Once you get used to quickevents instead of user events the next step is to collect all the programming for all the events of a window into one monolithic procedure - a commuter function. A commuter function needs parameters not just for the name (id) of the current control, but also which event called it, etc.

Promoted events are something different - a different kind of generalisation. E.g, you can have a promoted event that handles all GOTFOCUS events in all your windows. But in contrast to normal events there is no tailormade tool to help you establish them - no User Event Editor or QuickEvent dialog.

- Oystein -

Each member of the Sprezz collective insists on asserting independent thought by handling this different, but we are attempting to suppress that

.

My current prefered method is to try and "object" everything.

Each routine has a declaration such as

Function WindowName( Action, Entity, Param1, Param2, Param3, Param4, Param5, ErrorCode)

On the quickevent, the passed parameter line is generally

"ActionVal","@SELF"

For omnievents, we'll add "@PARAM1" to get the passed message.

By passing in the full entity name, you always have the window name.

WinID=Field( Entity, ".", 1 )

ControlName=Field( Entity, ".", 2 )

Each event type (click, lostfocus, changed) is a case statement, jumping to the correct code for that control.

Also, as a side note, when working with get/set_property, it's much faster to passed @RM delimited list of actions in a single go than it is to make seperate calls.

The Sprezzatura Group

World Leaders in all things RevSoft

Andrew,

Have you got some filter going that removes all content of your postings unless you comply with the company policy and sign with the Sprezzatura Group signature?

- Oystein -

We suspect an opera browser malfunction or an anonymizer glitch.

The Sprezzatura Group

World Leaders in all things RevSoft

Just goes to show you can't trust programmers.

- Oystein -

This is how we structure our commuter modules as well. The only difference is that we use a Locate statement vs. a Case statement.

[email protected]

SRP Computer Solutions, Inc.

heaven forfend one of us () has fat fingers!

The Sprezzatura Group

World Leaders in all things RevSoft

Well we actually use a mix - normally…

Locate Branch In "CLICK,LOSTFOCUS,CREATE"

Using "," Setting Pos Then

On Pos GoSub Click,Lostfocs,Create

End

Return

Click:

Begin Case

Case CtrlEntId=atWindow : ".BTN_OK"

</QUOTE>

…

The Sprezzatura Group

World Leaders in all things RevSoft

---

=== At 25 JAN 2001 10:13AM Donald Bakke wrote: ===

Now that's what I'm talking about .

[email protected]

SRP Computer Solutions, Inc.

---

=== At 25 JAN 2001 11:06AM The Sprezzatura Group wrote: ===

I'll try to resist the temptation to answer this simply to keep the Sprezz logo at the top …. oops failed…

Agree with Don about the logo btw…

The Sprezzatura Group

World Leaders in all things RevSoft

---

=== At 25 JAN 2001 11:43AM Donald Bakke wrote: ===

Thanks. Keep an eye out for our new website. Soon to be announced…

[email protected]

SRP Computer Solutions, Inc.

---

=== At 25 JAN 2001 12:21PM The Sprezzatura Group wrote: ===

We use locates as well. Who knows what I was thinking as that message was typed.

The Sprezzatura Group

World Leaders in all things RevSoft

---

=== At 25 JAN 2001 12:25PM The Sprezzatura Group wrote: ===

You presumably? Well actually knowing you, perhaps not…

The Sprezzatura Group

World Leaders in all things RevSoft

---

=== At 05 FEB 2001 08:36PM Scott, LMS wrote: ===

Hi All

Just to really rub it in, I looked up how to make the std proc run from the quick event.

effectively the click event on my run button had something like

CALL FORM_DETAILS_RRT(CtrlEntID, @WINDOW, err_dets)

and FORM_DETAILS_RPT was a subroutine with parameters

CtrlEntID, ThisWindow, Err_msg

a bit redundant I know, but you can't trust anything.

So the script on the click event got cleared and in the quick event stuff I put

entity (this radio button selected)

Using the arrow/browse to select stdproc executables, filled the box with

appname*STPROCEXE*FORM_DETAILS_RPT

message Execute

Parameters were

"@SELF","@WINDOW",""

ie err_msg is an output parameter

and it worked.

I now have a nice form that I can enter form names into and run a report, listing all its controls and any attached event code into a text file. Damn handy for figuring out what is going on with my code and converting it to commuter events.

Scott, LMS

PS why do I feel there is missing at least one post from Andrew-Sprezz and Donald Bakke's conversation about locates/on pos gosub and case statements. Personally I prefer case statements, but that is because of my PICK programming days where we had a corporate standard for case statements. I found them less prone to maintenance errors ie I can't count and I am dyslexic so lists get reordered in my head.

---

=== At 05 FEB 2001 11:09PM Donald Bakke wrote: ===

It's very easy to use Case statements as you have identified. I didn't use the Locate statement to the extent I am now for a long time. Then someone pointed out that Case statements are nothing more than nested if..then..end..else statements and could be very inefficient for long Case statements. Also, for commuter modules I like the fact that I don't have to scroll down very far before I find the real code.

[email protected]

SRP Computer Solutions, Inc.

---

=== At 06 FEB 2001 08:44AM Oystein Reigem wrote: ===

Scott,

Your next assignment is to turn FORM_DETAILS_RRT itself into a commuter function!

- Oystein -

---

=== At 06 FEB 2001 06:29PM Scott, LMS wrote: ===

Hi Oystein

How astute of you. It was the development of Form_Detail_Rpt that I used to test all the processes. I have a couple more bits to make it really nice like validation of Form names, and putting the browse button (for the output file directory) code into the commuter, but the run click is now a quick event calling the proc Form_Detail_rpt. I should probably have two different procs associated with this form.

1. Form_details_rpt_com (for the commuter events) This one should call the actual report and feed it the necessary parameters, that way I can call the report from elsewhere if I need to.

2. Form_Details_rpt (for the report/export to ascii text)

Howzat?

I have built quite a few tools that seem sadly missing from the oi development environment but can't figure out how to share them. A couple of them aren't really as bullet proof as I would like before sharing but nearly there. Most of them also use a function that calls message box instead of message box itself.

1. A flat_file function - given a directory and file name and a line of text (or a multiline var), write the lines to the ascii text file (flat file). It will create the file if it doesn't exist, or add to the end of it if it does, if the directory doesn't exist I think it returns an error but it is pretty reliable.

1. a search

a form that lets you enter a bunch of search strings, and a bunch of strings to exclude and search through forms, events and code (depending on what you select) for the strings. Output goes to the flat file (ascii text) of your choice.

2. A copy records given a selection criteria

ie select all these records and copy somewhere else.

3. A reset field given a selection criteria, get all the records meeting this criteria and reset the field. Damn handy when the client stuffs a batch run

4. A delete multiple records given a selection criteria. This is the exciting one - it could use a bit more work but it is ok for now.

5. A Dos file names report in OIPI that lists out all the tables in SYSTABLES and their dos file equivalent names, a bit like listmedia/listvolumes in AREV. I select the whole of systables, then for each table found, I read a record from it, then I read the systables record to get the details. It isn't 100% but it's close, and certainly good enough to quickly identify which data files I need to back up before I do the delete records thing, and also if the .lk file is sized much different to the .ov file

6. The form_detail_rpt

as described. Lists controls and event code.

And it works much better when you don't assign the same handle variable name to the event table as the wins table.

7. A table exporter to ascii

This thing could probably use some more work before I share it, but essentially it lets you enter in a list of fields that you would like exported from a particular table, a selection criteria to limit it, and delimiter of choice or fixed width etc, save that map, and run to export. If there are multivalue fields it will export one line for each multivalue in the list in a reasonably coherent way, ie if you export from the one table the key fields, and a set of multivalues that are associated with each other, then it exports one line for each multivalue. It needs some work so that it fills in the single value key values for each line - I ended up writing a fill in the blanks macro for excel to get around that problem, but it might be easier to make modification to the OI end.

It would be really nice if part of the table definitions allowed you to define which multivalue fields were associated with each other, so that if you had several different "associations" in one table (yeah, I didn't design it - ok) you can pick them out to generate the export structure.

What I'd like to create but haven't yet (or may not be able to)

A. A "who has that table or record locked?" function

B. a "chuck everyone off OI except me" routine.

C. a "report writer" that allows users to paint their reports and enter selection criteria, and make the output in OIPI

D. a system that allows infinite (given sufficient hard disk space) dynamic arrays, edit tables, record sizes, indexes etc. I am already 3/4 the way through developing a paging system for edit tables. The commuter event concept should help heaps with this. I got the paging to work but the update stuff, where you add, edit and delete rows in the table, is still a bit screwed.

E. Something like TCL and VOC that will allow me to create "paragraphs" to run adhoc reports that include inline prompts that allow the users to run these with different parameters. (Hear the PICK/Universe programmer?

F. I probably need to make some sort of admin program to verify, and then resize tables that are getting lopsided. I hate the fix gpf thing because it always eats a record and I don't know which one, so running the verify is a bit terrifying, because if I get a GPF, I have to get a restore from tape, because most of the vulnerable data is financial, and we can't overlook a bill just because the database ate it. (the dog ate my homework)

What I was hoping would be allowed but licences have gotten strange about it was the run time ability to do the following

X. Create tables (eg for report extract data into a manageable size)

Y. Copy tables (same, for reports)

Z. Modifiy tables. (for updates) I wouldn't do this on the fly but it is damn difficult chucking everyone off including the index machine so I can put an update on that includes new bits of system.

And then the I'm dreaming section:

i. 32 bit/64 bit, what ever is going, inc linux OI

j. something that doesn't die when the network does

k. something where the record locking doesn't allow updating a record by two people at once ie I have largely cured it but we were doubling up on generated records and manually created records in the same file even when the record/keys were locked by one of the systems. I'd like the database to be as reliable as Oracle or DB2.

l. A system that works much faster than the current one.

m. a boss that will pay for the upgrade/support tools.

Beam me up

Scott

---

=== At 07 FEB 2001 07:27AM Oystein Reigem wrote: ===

Hi Oystein

How astute of you. It was the development of Form_Detail_Rpt that I used to test all the processes. I have a couple more bits to make it really nice like validation of Form names, and putting the browse button (for the output file directory) code into the commuter, but the run click is now a quick event calling the proc Form_Detail_rpt. I should probably have two different procs associated with this form. 1. Form_details_rpt_com (for the commuter events) This one should call the actual report and feed it the necessary parameters, that way I can call the report from elsewhere if I need to. 2. Form_Details_rpt (for the report/export to ascii text) Howzat?

I'm not sure I understand what you mean. But I think I'd hang on to the principle of having all the code associated with the form in one commuter function.

And let the commuter function have exactly the same name as the form. That's so neat.

And use the parameter convention

function XXXX( Event, CtrlEntID, Param1, Param2, Param3, Param4, Param5, Param6, Param7 ).

Let me present a different example and see if that's what you mean:

Let's say you have a form with three buttons A, B and C.

Let's say A needs to do

aaaaaa

aaaaaa

aaaaaa,

B needs to do

bbbbbb

bbbbbb

bbbbbb,

and C needs to do

cccccc

cccccc

cccccc.

Then you can make a commuter function

…

begin case

case …A…

. aaaaaa

. aaaaaa

. aaaaaa

case …B…

. bbbbbb

. bbbbbb

. bbbbbb

case …C…

. cccccc

. cccccc

. cccccc

case true$

. …end case

…

Right?

Then let's say there's something else than this form that needs to do

cccccc

cccccc

cccccc

Then you can just put that cccccc programming in a function CCC and have the commuter call that:

…

begin case

case …A…

. aaaaaa

. aaaaaa

. aaaaaa

case …B…

. bbbbbb

. bbbbbb

. bbbbbb

case …C…

. Ret=CCC( … )

case true$

. …end case

…

Or?

- Oystein -

---

=== At 07 FEB 2001 08:01PM Scott,LMS wrote: ===

Hi Oystein

I am up to the bit where I start converting the existing structure to the new commuter event called by quick events. I have a lot of code that looks like

*event script

* eg form * create event

* main

 gosub do_stuff

 if thingy then

    result=true$

 end else

    result=false$

 end

return result

do_stuff:

* stuff

* set thingy in here

return

Do I just "return result" at the end of my commuter event?

And yes I am thinking on the same wavelength as you but mostly CtrlEntID is my first param on most of my routines that use it, although I might change that for sake of Rev community standards. And my case statement would look something like

begin case

 case action=action1"

    gosub do_action1

 case action=action2"

    gosub do_action2

 case ...

end case

return result ;* I'll soon find out if this works.

My form names, I will try to use the same name for the commuter event but mostly where the form is for report parameters, the proc with the same name as the form is the report proc. And some of those are already split because of the 64K char limit. So I might end up with

form: formname

commuter proc: formname_frm

report proc: formname or formname_rpt

Just so long as they are easy to find.

I am thinking to write a proc called appname_frm because there is a standard set of code that goes in all our forms' activated, close and inactivated events.

And it is slightly bizarre to write a form to report on the event script code, and use no event script code in that form. This is what happens when your coding practice is in transition. I wonder how many other good OI coding practices there are that I don't know about. I am particularily interested in the one that sprezz seems to be using to drive their database access using html on browsers. I suspect I don't have the right version and additions of OI to do this.

Scott.

---

=== At 08 FEB 2001 12:16AM Scott, LMS wrote: ===

Hi Oystein

Hope you still visit…

I need to know what @@WINDOW is, can I use

my_window=field(CtrlEntID, '.', 1)

then @my_window

I think it was used in the context of setting focus

ie

@@WINDOW-]FOCUS=1

and in the create event, it uses values that were in the createparam - how do I get this to pass to a quick/commuter event?

Scott.

---

=== At 08 FEB 2001 03:07AM The Sprezzatura Group wrote: ===

@Window remains for use in your routines. So

atWindow=@Window

is legitimate.

To pass to a commuter module from a quick event use "@WINDOW", "@SELF" for CtrlEntId etc etc - drop down a list of controls to see the other @Variables. Note these are "Pseudo @Variables" which get swapped out by the system rather than evaluated like @Fm et al.

The Sprezzatura Group

World Leaders in all things RevSoft

---

=== At 08 FEB 2001 04:34AM Oystein Reigem wrote: ===

Scott,

You can't use that control-]property syntax in a stored procedure, only in user events.

- Oystein -

---

=== At 08 FEB 2001 05:20AM Oystein Reigem wrote: ===

Scott,

Sorry for mauling the formatting of your posting's text in this reply. I didn't want to chuck anything out, but wanted to keep down the number of lines.

Besides it was good fun!!!!

I am up to the bit where I start converting the existing structure to the new commuter event called by quick events. I have a lot of code that looks like *event script * eg form * create event * main gosub do_stuff if thingy then result=true$ end else result=false$ end return result do_stuff: * stuff * set thingy in here return

Do I just "return result" at the end of my commuter event?

The commuter is run by the quickevent. You can't return a value the same way as when you call a procedure from a different procedure. But that's not the commuter's fault. It's the same thing with user events. There's no main program to return a value to. With OI the code is all diced up into single events. You must largely return values by setting properties (regular or user-defined) of controls. Or in common variables. If an error occurs, the event code might have to issue an error message, or do some cleanup, or close the form, or whatever. It can't just return an error status and leave the whole problem to some superior or responsible code, because there isn't any as far as you're concerned. Is this what you're thinking of, or have I misunderstood completely?

(And you don't return 0 or 1 either, like you do in user events, to halt or continue the chain of processing.)

Note that a quickevent itself can just handle one returned value - put that value in a single property of a single control. A stored procedure run by the quickevent, on the other hand, can set many properties. I find myself setting properties from the event code (i.e, the stored procedure, i.e, the commuter function) most of the time, and leave the quickevent Return value in Control/Property fields blank. I don't know if that's a bad habit in general.

And yes I am thinking on the same wavelength as you but mostly CtrlEntID is my first param on most of my routines that use it, although I might change that for sake of Rev community standards. And my case statement would look something like begin case case action=action1" gosub do_action1 case action=action2" gosub do_action2 case … end case return result ;* I'll soon find out if this works.

Looks fine. (Myself I hate gosubs, because internal subroutines are such a messy concept, but used like this they can't do much harm.)

My form names, I will try to use the same name for the commuter event but mostly where the form is for report parameters, the proc with the same name as the form is the report proc. And some of those are already split because of the 64K char limit. So I might end up with form: formname commuter proc: formname_frm report proc: formname or formname_rpt Just so long as they are easy to find.

Agree.

I am thinking to write a proc called appname_frm because there is a standard set of code that goes in all our forms' activated, close and inactivated events.

Some such code might be placed in promoted events. Note I don't promote the use of promoted events (duh). Myself I'm not at the level yet where I use them with confidence.

And it is slightly bizarre to write a form to report on the event script code, and use no event script code in that form. This is what happens when your coding practice is in transition. I wonder how many other good OI coding practices there are that I don't know about. I am particularily interested in the one that sprezz seems to be using to drive their database access using html on browsers. I suspect I don't have the right version and additions of OI to do this.

S/WEB? Sprezzatura better comment on that. I thought I'd check the latest development on their web site, but it's not mentioned any more. Still work in progress, perhaps. I'm sure it's brilliant. Among other things they have written their own cgi.

- Oystein -

---

=== At 08 FEB 2001 07:05AM The Sprezzatura Group wrote: ===

The Web site is being redone at the moment so S/Web references do not abound . The internal documentation remains at www.sprezzatura.com/SWEB.HTM but it isn't linked to yet. We're just going live at several sites and want them up and running before we link it in!

Just FWIW it isn't CGI - it's next generation ISAPI . Means we don't have to load an executable every time we get a request as it is a DLL.

The Sprezzatura Group

World Leaders in all things RevSoft

---

=== At 08 FEB 2001 08:02PM Scott wrote: ===

Hi All

There is a super-application to my main application that has "procedures" and "activities" where the procedures are collections of "activities". The process that initiates the activity, usually calls up the forms that I am trying to make commuter events, but when the form gets Created, a whole bunch of stuff gets passed from the super-application to the form, so I was wondering how to pass the stuff from the super-application to the form create commuter event without "createparam" - not sure I can from your answers.

And the other thing was not @Window or atWindow but @@WINDOW - what is this? The parent of the current window? ie if one window calls another window is @@WINDOW (used in the second (child) window) the first (parent) window? I couldn't look at it with debug, system variables and I couldnt assign it to something ie myvar=@@WINDOW got syntax errors. The actual event had if problem then @@WINDOW-]FOCUS=1, which I need to change to something else but what is @@WINDOW? and is @my_window the same as @@WINDOW ie if my_window=@WINDOW?

For now I think I will use the commuter event for stuff like control validation, and lookups and running reports but leave the create/inactive/close stuff as regular event scripting.

Scott.

---

=== At 09 FEB 2001 05:27AM Oystein Reigem wrote: ===

Scott,

The @ and @@ and . and -] stuff is docced in the paper mans. See Section 4 of Guide to App Devel.

With @Window it's like this: Let's say you have a window named MYWINDOW. Then you can get the TEXT property (i.e, the caption) with

Caption=MYWINDOW-]TEXT

If you instead have a variable WindowName that contains the name ("MYWINDOW") you must do

Caption=@WindowName-]TEXT

@Window is a variable that contains the name of the current window. To do the same with @Window instead of WindowName, you must still put an @ in front of the variable name, i.e:

Caption=@@Window-]TEXT

(So the two @s mean different things. If you look closely you will see they look a bit different too. Use a good quality scanning tunnelling microscope.)

- Oystein -

---

=== At 11 FEB 2001 10:37PM Scott, LMS wrote: ===

Hi Oystein

About time I had a good look in that book. Maybe I will learn the "Revelation Technologies Way". And maybe not.

Thanks for persisting with this thread - I definitely think it has been worth it.

Scott.

---

=== At 15 FEB 2001 12:47AM Scott, LMS wrote: ===

In the interests of completeness

HREF=http://www.revelation.com/WEBSITE/DISCUSS.NSF/09d90959a1a106db8525652c0042cb86/40E5E9388D071165852567300074C41E?OpenDocument" Focus ID for lost focus events

ie

FocusID=Get_Property('SYSTEM','FOCUS')

I needed that bit of information when I was converting my lost focus code. I couldn't figure out how that thing was getting set, and my commuter event didn't like having it unassigned. Next time I might remember to look at the event script parameters.

Scott

---

=== At 15 FEB 2001 12:49AM scott, lms wrote: ===

HREF=http://www.revelation.com/WEBSITE/DISCUSS.NSF/09d90959a1a106db8525652c0042cb86/40E5E9388D071165852567300074C41E?OpenDocument" Focus ID for lost focus events

maybe i forgot the last square bracket…

---

=== At 15 FEB 2001 12:52AM Scott, LMS wrote: ===

Focus ID for lost focus events

Nope It must be something else like I forgot how to put the HTML together?

View this thread on the forum...