To all,

Testing OI 8.0.8 and when calling a dialog box and closing, I'm seeing these various message. Can someone (RTI??) shed some light on this? Are they related? Or do they indicate separate problems.

Also, in the one case that I'm testing, after the initial "error msg", when I do the same thing again (without logging off), thing may behave properly. Does this provide a clue? It's like the condition causing the error is temporarily gone. But if I logoff and come back in I see the problem again.

Thanks,

Ray Chan

RTI (or anyone),

Running OI8.08, there a difference between OI7 and OI8. We're hitting the FORM_CLEAR and OWIN_FORMLOAD pretty reliably.

I'm still trying to narrow down this bugger (so we can fix), but do you have any suggestion on what causing FORM_CLEAR, OWIN_FORMLOAD, or SEMANTICLOGICLAYER to generate versus the run of the mill RUN_EVENT?

Still digging, but some insights might be helpful.

Thanks,

Ray Chan

Do you have forms that use STYLESHEETS you need to remove them field 3 in the form, the first subfield, if there is one it will look something like *, you can delete the subfield up to the marker and save. Then use fordes to recompile, If that fixes, then I have a ssp that specifically looks for a fixed string (BSBS*STYLESHEET) in front of and removes if found and recompiles, so I can send you that.

Hi Barry,

We're not using STYLESHEETS.

Would the use of STYLESHEETS cause the kind of error messages that I'm seeing?

Appreciate your response. Any other thoughts welcome This is tiring work.

Ray

Ray,

Are you getting the error on every window or just on Dialog_box calls? If so what are you doing on your close of the dialog that is freeing the common? 8.0.8 is not the latest version of the software, 9.2 is the latest version and the recommended version to use.

Sean

Hi Sean,

First let me say that we plan to move to OI9, but for now, we're moving to OI808. One step at a time. I'm assuming that OI808 is still supported.

The general scenario is this: From an MDIFrame, we call an MDIChild. From this MDIChild, we may call from an Editline (via right-click or Lostfocus)a dialog box that is databound. We make a change and Save. This is when we get the unusual FORM_CLEAR, OIWIN_FORMLOAD, etc. error message. Below is a recent CALL STACK. Does this offer any insights?

We are closing these form with a POST_EVENT CLOSE (note in the CALL STACK we don't see the CLOSE) and don't see anything wrong in our code, but we are still poking. We haven't given up yet.

At this point our code is very stable (OI7). As you know, we have been a long-time member of the Rev community and hope to continue.

Trust me we want OI8 to work so we can move to OI9 and be ready for OI10.

Any help/insight you can provide would be appreciated. Thanks also to my other brothers in the Rev community.

Ray Chan

Hi Ray,

The major change in Dialog_Box() behaviour between OI7 and OI8 is that the dialog_Box modal loop is now "internal" to the PS rather than "external", i.e. it no longer runs inside a Basic+ loop inside the engine (which usually eats up 100% CPU and brings a lot of terminal service-based OI systems to their knees).

From what I can see from the call stack above the POST_EVENT() CLOSE has already been executed some time before one of the routines you mention (FORM_CLEAR, SEMANTICLOGICLAYER etc) is executed - therefore the common is released and you get the error :(

So, how can this happen? Well, when you issue a Post_Event() call there's no guarantee *when* it will execute - you're just saying that you want it to execute when the system thinks it's got a spare timeslot - underneath the hood the PS uses the standard PostMessage Windows API call to trigger the event, so it will get processed when the PS next checks it message queue and the engine is considered to be "idle".

In the OI8+ dialog_Box() model there is indeed a message processing loop (otherwise you wouldn't be able to interact with the dialog) and this is seeing the posted CLOSE event and then asking the engine if it is idle. If the Basic+ code in the engine is processing a yield() statement at that point then the engine _is_ considered to be idle - and in this case the posted CLOSE will be executed. It is easily possible for a yield() statement to be found inside SEMANTICLOGICLAYER and the like.

That's the most likely theory I have for why you are seeing this error :)

So, I can suggest two solutions:

1) Restructure your code to avoid the Post_Event. I know this may be painful but I would consider altering your code so that you close the dialog via end_dialog() after all your saving and clearing is done if possible. Make the close the last thing you have to do - this is always good practice.

2) This might not work (i.e it's untested) but you could try using the SYSTEM HOLD_EVENTS property to delay the posted CLOSE event until your WRITE etc is out of the way?

Sorry for the long-winded explanation - hope it makes sense!

cpates@sprezzatura.com

Captain's Blog

Battlestar Sprezzatura - BSG 77

Colonial leaders in all things RevSoft

Hi Captain C,

What a pleasant surprise. I just logged into the forum and see your response, but unfortunately I have to pick up someone and need to leave soon :(

Nevertheless, I just quickly tried the End_Dialog and this still yield the "Freed common error" message. (I'm still using @window) I'm not familiar with the SYSTEM HOLD_EVENT. I'll probably need some assist on that.

I wish I could stay longer. I love your work ethic and willingness to help on a weekend

Thanks for response. Enjoy your day. I'll try to come and play more when I can.

Ray

Hi Captain C and/or Anyone,

So, how can this happen? Well, when you issue a Post_Event() call there's no guarantee *when* it will execute - you're just saying that you want it to execute when the system thinks it's got a spare timeslot - underneath the hood the PS uses the standard PostMessage Windows API call to trigger the event, so it will get processed when the PS next checks it message queue and the engine is considered to be "idle". In the OI8+ dialog_Box() model there is indeed a message processing loop (otherwise you wouldn't be able to interact with the dialog) and this is seeing the posted CLOSE event and then asking the engine if it is idle. If the Basic+ code in the engine is processing a yield() statement at that point then the engine _is_ considered to be idle - and in this case the posted CLOSE will be executed. It is easily possible for a yield() statement to be found inside SEMANTICLOGICLAYER and the like. That's the most likely theory I have for why you are seeing this error :)

I played a bit more with no success for now. I have several questions if your theory is correct. Maybe RTI may wish to comment as well:

1) Would this behavior carryover to OI 9? RTI?

2) Is this a bug or a feature?

3)Does RTI have a suggested workaround or suggestion if this theory is correct? Stay at OI7 for now?

4) Have other developers encounters this sympton? If so, I don't recall many piping up over this. Or did they have a workaround when beta testing? Or are we unique? I just happened to stumble over and am kind of stuck and stubborn until this works. I was so hopeful too after I made the upgrade to OI808.

Thanks again for your meaty analysis/theory.

Ray Chan

OK having gotten to the bottom of this we thought it'd be instructive to post a quick update.

The problem boiled down to event flow. As Capt C pointed out Dialog_Box was reengineered for 8+ and part of this reengineering meant that events could be processed in the dialog box loop.

Ray's system uses an unusual way of calling dialog boxes. This is why nobody else has seen this issue. Some promoted code was POSTing a CLOSE on the PRE WRITE promoted event and by the time the FORM CLEAR logic was being called the CLOSE had been processed so the FORM CLEAR logic did not have the labelled common it required to function correctly.

We have provided Ray with a couple of possible work arounds.

So to answer the questions above :-

1) Yes this behaviour will carry forward to 9

2) It is a feature. :)

3) For RTI to say

4) No :(

Regards

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

View this thread on the forum...