›
Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Panel Frozen

ColinRuleColinRule
in SRP Panel Control
I have a panel, with various controls including some buttons which call code to process a rebuild of an index.
The process uses a form to advise as a progress bar, ie CREATE_DIALOG to start it off, feeds properties to update progress end END_DIALOG to close.

The action of doing this dialog box causes the panel form to hang, nothing clicks or gets focus.
I have tried a redraw just in case it is that.

If I run the same form outsize the panel all works fine.
The progress bar form and events have been in use for many years so I doubt it is anything within this specifically.
It just seems like the create dialog/end dialog is upsetting it.

I have actually worked around this by using the progress panel within the containing screen to show progress rather than as a separate form, but thought I would record here in case you feel the need to investigate.

Colin

Comments

  • DonBakkeDonBakke
    Colin,

    I get that this works fine when you do not launch this from the SRP Panel control so I am not questioning your technique. I do want to better understand the intent So if you don't mind I am going to ask a few clarifying questions:
    • You are launching the Create_Dialog as a modeless dialog, correct?

    • When you are unable to interact with the SRP Panel control, is the Create_Dialog doing anything on its own, like running a TIMER event or is it purely idle waiting for other processes to interact with it?

    • Are you running any other processes, like a loop, when this problem occurs?

    • You said the form is used for displaying progress. Is the dialog getting progress updates at the time when the SRP Panel control is unresponsive?
  • ColinRuleColinRule
    Don

    The create is done via:
    CALL CREATE_DIALOG("STD_PROCESS",@WINDOW,0,CREATEPARAM)

    The inability to interact with the form is AFTER the loop process has completed, and the dialog has been closed.
    There is no TIMER involved, and in any case does not matter as the dialog is closed.
    I even tried just creating and closing the dialog, and get the same result, ie with no processing loop involved.

    Colin
  • DonBakkeDonBakke
    Colin,

    My apologies. You said the form was closed but I overlooked that comment while I was responding.

    What happens if you close the form manually? What about using End_Window?
  • ColinRuleColinRule
    Closing the form manually does not make any difference, problem still occurs
    Tried End_Window, and exactly the same.
    • CALL CREATE_DIALOG("STD_PROCESS",@WINDOW,0,"")
    • CALL END_DIALOG("STD_PROCESS")

    This is the code, commented out now, but I can reinstate to test.
    Seeing as closing the window manually, or via End_dialog is still not resolving, it might be the create.
    I tried a different form, just any old usual form I have, and get the same.

    Colin
  • DonBakkeDonBakke
    Colin,

    I truly appreciate your willingness to jump through these hoops. It wouldn't surprise me if you asked yourself the question, Why doesn't Don just test this himself? The simple answer is, I don't have an application handy with the SRP Panel control and I don't have the time to create a sample form. So, for now I hope you will continue to indulge me. Also, I must add that our senior engineer in charge of ActiveX controls is away on a three month assignment so I am not expecting him to be as quick to respond.

    My instincts are telling me that this is a focus problem. When a dialog box is closed, OI looks for a control on the parent form to give focus to. The SRP Panel control is unusual in this respect. This scenario also has me curious as to why this has never been reported before.

    For instance, if what you have reported is universally true with dialog boxes, then one would expect a call to Msg() to have the same problem. Have you tried this?

    Have you tried setting focus to an edit control when the form is closed? With regard to the buttons you use to launch the dialog box, what kind of buttons are these - SRP Buttons or OI buttons? If SRP Buttons, what kind of style are you using?

    Hopefully this will shed light onto the nature of the beast if not offer some means of taming it as well.
  • ColinRuleColinRule
    Thanks Don

    I was thinking of asking you 'that' question, but I thought not to, as it may be something strange I am doing, but I doubt it.
    Happy to jump through the hoops as needed.
    As I have a workaround, it is not critical to resolve, so just trying to fathom why it would occur for your general user base, but also there could be another case of this elsewhere if I use a panel again.

    The code that launches the process is from an OI button call to code in the calling forms OMNIEVENT.

    I tried MSG and got the same.
    I used the code below, copied from the MSG help from OI.

    I also set the focus to a text control on the form, and this did not make any difference.
    I tested this without the panel, giving focus to another control, clicked the button and focus went to the coded control.
    Did the same from the Panel and still stuck.
    Def = "" Def<1> = "Processing..." Def<2> = "U" display the processing message and do the processing MsgUp = Msg(@window, Def) take down the processing message Void=Msg(@window, MsgUp) CALL SET_PROPERTY("ELEMENT_SETS.SET_DESC","FOCUS",1) return
  • DonBakkeDonBakke
    Colin,

    I am somewhat relieved that even Msg(), especially when called as an Up Banner message, has the same problem. This tells me the problem is universal with modeless dialog boxes.

    I realize a modal dialog box defeats the purpose for what you need (i.e., it cannot be updated as a progress display as you intended), but would you mind calling Msg() using a simple syntax like this:

    rv = Msg(@Window, 'Hello World!')

    What I am wondering now is whether modal dialog boxes that get closed also exhibit the same problem.

    I want to clarify something you wrote. You said that you "set the focus to a text control on the form". Did you mean an edit control of some kind? When I read "text control" I normally think of "static text control", which of course cannot receive focus.
  • ColinRuleColinRule
    Don

    Tried MSG, message displayed, when closed the form works properly.
    Hence Modal dialogs seem OK.

    Yes, I meant an edit line control

    Colin
  • DonBakkeDonBakke
    Colin,

    My guess is that the modal dialog is more successful because it suspends the calling process and keeps everything under tight control. What bothers me is that simply calling a modeless dialog can result in this behavior. In my mind, what is the difference between that and - for instance - launching a window within the application from a control outside of the SRP Panel?

    Hmmm...how about calling Create_Dialog without a parent argument or setting the parent to something other than the window with the SRP Panel control?

    Also, in your tests, can I assume that you did a Create_Dialog immediately followed by an End_Dialog? That is, no other code was executed in-between?
  • ColinRuleColinRule
    Don

    I tried with no parent argument (ie null) and strangely the dialog did not display.
    I have seen this before, when a dialog calls a dialog, or even three layers deep, it fails to run.
    I believe this is an OI problem, perhaps a limitation.

    I have in the past come up with a workaround to this situation... although very rare.
    What I do is send a message to the main screen and get this to do the create-dialog, thus removing a layer of dialog recursion.

    It did not however cause the form to hang, but maybe that is because it did not run in the first place.
    In testing the end dialog was immediately following the create, although I have also tried like this and with a 5 second delay.

    Maybe this is part of the issue, in that OI has some grief with several layers of dialog, and perhaps it thinks it started, disables access to the calling form, but fails to release it, hence the calling form remains disabled.

    Colin
  • ColinRuleColinRule
    In a new usage of the Panel, in an existing form, I had the same problem, the screen hung after a specific event.
    I was able to trace the cause of this, and found a solution.

    Within the Panel I had a call to a create dialog, showing a progress bar form.
    Call CREATE_DIALOG("ICEPAC_PROCESS",@Window,0,CreateParam) This caused the Panel form to hang.
    I commented out this line and the form works fine.

    It seems that if the dialog is owned by the Parent, and not the Panel, then it works.
    So, this line instead runs and the panel form no longer hangs.
    Call CREATE_DIALOG("ICEPAC_PROCESS",ParentWindow,0,CreateParam) Colin
  • DonBakkeDonBakke
    Colin,

    Within your application, what is in @Window and what is in ParentWindow?
  • ColinRuleColinRule
    @WINDOW is the Panel form.
    ParentWindow is the form which contains the Panel
  • DonBakkeDonBakke
    Colin,

    Ahhhhh...I see. Yes, @Window would have been the form which is itself subclassed into the Panel control. I think it just never occurred to me that the event handler is coming from parent form of the Panel control. This is why I was surprised by the behavior you explained. However, now that this has been made clearer to me, I think my original theory is correct. It is a focus issue but the subclassed form is really in an odd state of existence and I don't think OI truly knows how to handle this. Therefore, your work around is probably the best practice design. Good job.
Sign In or Register to comment.