Skip to main content

bandicam-2018_2D00_02_2D00_12-08_2D00_48_2D00_28_2D00_183.mp4

 Okay so this might be a little difficult to explain.  Basically we have a cobol screen that has a .net assembly embedded in the screen section. When one of the assemblies functions is activated(which displays another form overlayed on the screen, not another window) the cobol window that had focus loses it's focus, and focus is transferred to last active windows screen that WASN'T controlled by the acucobol runtime(i.e. file explorer). This behavior does not happen when the .net assembly is embedded on a standard windows form outside of the acucobol runtime(i.e. as a simple executable).

We tried switching the .net assembly to run as a stand alone windows form rather than being embedded, but we have a situation where we do not want users to be able to "touch" screens 2 and 3(numbers being screen depth) and the assembly is screen 4.  When the assembly is run, all screens are able to be "touched" whereas before they could not be touched until the old screen 4 was closed.  Not sure if that makes sense, but that is what we are dealing with.  We ARE using a 3rd party control(the assembly is created by us, but the assembly contains other 3rd party dll's), but we can reproduce this behavior without the 3rd party controls.

 

It's a little difficult to see in the video because you can't see the mouse, but I am basically clicking the filter drop down icon(creates new windows form, focus is lost from main window, which is standard behavior).  Nothing happens and we are good.  As soon as I click in the main grid area, it SHOULD transfer the focus back to the main window, but as soon as I click anywhere on the screen(grid or not) it looks like the runtime is essentially hijacking the focus transfer and sending it back to the last active screen.  Focus transfers fine if I click another application(i.e. file explorer)
 


#AcuCobol
#.net

bandicam-2018_2D00_02_2D00_12-08_2D00_48_2D00_28_2D00_183.mp4

 Okay so this might be a little difficult to explain.  Basically we have a cobol screen that has a .net assembly embedded in the screen section. When one of the assemblies functions is activated(which displays another form overlayed on the screen, not another window) the cobol window that had focus loses it's focus, and focus is transferred to last active windows screen that WASN'T controlled by the acucobol runtime(i.e. file explorer). This behavior does not happen when the .net assembly is embedded on a standard windows form outside of the acucobol runtime(i.e. as a simple executable).

We tried switching the .net assembly to run as a stand alone windows form rather than being embedded, but we have a situation where we do not want users to be able to "touch" screens 2 and 3(numbers being screen depth) and the assembly is screen 4.  When the assembly is run, all screens are able to be "touched" whereas before they could not be touched until the old screen 4 was closed.  Not sure if that makes sense, but that is what we are dealing with.  We ARE using a 3rd party control(the assembly is created by us, but the assembly contains other 3rd party dll's), but we can reproduce this behavior without the 3rd party controls.

 

It's a little difficult to see in the video because you can't see the mouse, but I am basically clicking the filter drop down icon(creates new windows form, focus is lost from main window, which is standard behavior).  Nothing happens and we are good.  As soon as I click in the main grid area, it SHOULD transfer the focus back to the main window, but as soon as I click anywhere on the screen(grid or not) it looks like the runtime is essentially hijacking the focus transfer and sending it back to the last active screen.  Focus transfers fine if I click another application(i.e. file explorer)
 


#AcuCobol
#.net
This isn't a fix, but in order to make your .NET screen a child of the AcuCOBOL screens, you need to do an inquire for "SYSTEM HANDLE" on your primary window into an UNSIGNED-INT, and pass that value to the function which opens the .NET window. If you pass that as handle into the Show() or ShowDialog() method, your users won't be able to access the COBOL windows as long as the .NET window is open. Bear in mind that this is very messy when you're debugging (you can't access the debugger either), so we have a flag that indicates when we're likely to be debugging, and it always passes a zero for the main window handle.

-Chris

bandicam-2018_2D00_02_2D00_12-08_2D00_48_2D00_28_2D00_183.mp4

 Okay so this might be a little difficult to explain.  Basically we have a cobol screen that has a .net assembly embedded in the screen section. When one of the assemblies functions is activated(which displays another form overlayed on the screen, not another window) the cobol window that had focus loses it's focus, and focus is transferred to last active windows screen that WASN'T controlled by the acucobol runtime(i.e. file explorer). This behavior does not happen when the .net assembly is embedded on a standard windows form outside of the acucobol runtime(i.e. as a simple executable).

We tried switching the .net assembly to run as a stand alone windows form rather than being embedded, but we have a situation where we do not want users to be able to "touch" screens 2 and 3(numbers being screen depth) and the assembly is screen 4.  When the assembly is run, all screens are able to be "touched" whereas before they could not be touched until the old screen 4 was closed.  Not sure if that makes sense, but that is what we are dealing with.  We ARE using a 3rd party control(the assembly is created by us, but the assembly contains other 3rd party dll's), but we can reproduce this behavior without the 3rd party controls.

 

It's a little difficult to see in the video because you can't see the mouse, but I am basically clicking the filter drop down icon(creates new windows form, focus is lost from main window, which is standard behavior).  Nothing happens and we are good.  As soon as I click in the main grid area, it SHOULD transfer the focus back to the main window, but as soon as I click anywhere on the screen(grid or not) it looks like the runtime is essentially hijacking the focus transfer and sending it back to the last active screen.  Focus transfers fine if I click another application(i.e. file explorer)
 


#AcuCobol
#.net
It does behave as you stated, but that gets rid of the behavior we need. Screen 1 should still be active and able to be acted upon, but screen 2 and 3 should be "frozen", and send the focus back to screen 4. This works currently with the control embedded, but then when we click the filter drop down for whatever reason the runtime is interjecting its self. I even added an event handler just to throw a message when the filter drop down form is closing, and on the first close it issues before the focus hop, but sometimes it works(issues messagebox) and sometimes it doesn't(form closes but no messagebox is issued). It is honestly very weird. If I do the same event on a standalone program with just the grid on a standard windows form it issues the message box every time.

bandicam-2018_2D00_02_2D00_12-08_2D00_48_2D00_28_2D00_183.mp4

 Okay so this might be a little difficult to explain.  Basically we have a cobol screen that has a .net assembly embedded in the screen section. When one of the assemblies functions is activated(which displays another form overlayed on the screen, not another window) the cobol window that had focus loses it's focus, and focus is transferred to last active windows screen that WASN'T controlled by the acucobol runtime(i.e. file explorer). This behavior does not happen when the .net assembly is embedded on a standard windows form outside of the acucobol runtime(i.e. as a simple executable).

We tried switching the .net assembly to run as a stand alone windows form rather than being embedded, but we have a situation where we do not want users to be able to "touch" screens 2 and 3(numbers being screen depth) and the assembly is screen 4.  When the assembly is run, all screens are able to be "touched" whereas before they could not be touched until the old screen 4 was closed.  Not sure if that makes sense, but that is what we are dealing with.  We ARE using a 3rd party control(the assembly is created by us, but the assembly contains other 3rd party dll's), but we can reproduce this behavior without the 3rd party controls.

 

It's a little difficult to see in the video because you can't see the mouse, but I am basically clicking the filter drop down icon(creates new windows form, focus is lost from main window, which is standard behavior).  Nothing happens and we are good.  As soon as I click in the main grid area, it SHOULD transfer the focus back to the main window, but as soon as I click anywhere on the screen(grid or not) it looks like the runtime is essentially hijacking the focus transfer and sending it back to the last active screen.  Focus transfers fine if I click another application(i.e. file explorer)
 


#AcuCobol
#.net
Sorry, I misunderstood what screens you were trying to prevent access to. Maybe getting the system handle to Screen 2 and passing that? Just a guess. I have also noticed some very strange focus issues when mixing AcuCOBOL and .NET, so I try to keep the lines as "clean" as possible.

bandicam-2018_2D00_02_2D00_12-08_2D00_48_2D00_28_2D00_183.mp4

 Okay so this might be a little difficult to explain.  Basically we have a cobol screen that has a .net assembly embedded in the screen section. When one of the assemblies functions is activated(which displays another form overlayed on the screen, not another window) the cobol window that had focus loses it's focus, and focus is transferred to last active windows screen that WASN'T controlled by the acucobol runtime(i.e. file explorer). This behavior does not happen when the .net assembly is embedded on a standard windows form outside of the acucobol runtime(i.e. as a simple executable).

We tried switching the .net assembly to run as a stand alone windows form rather than being embedded, but we have a situation where we do not want users to be able to "touch" screens 2 and 3(numbers being screen depth) and the assembly is screen 4.  When the assembly is run, all screens are able to be "touched" whereas before they could not be touched until the old screen 4 was closed.  Not sure if that makes sense, but that is what we are dealing with.  We ARE using a 3rd party control(the assembly is created by us, but the assembly contains other 3rd party dll's), but we can reproduce this behavior without the 3rd party controls.

 

It's a little difficult to see in the video because you can't see the mouse, but I am basically clicking the filter drop down icon(creates new windows form, focus is lost from main window, which is standard behavior).  Nothing happens and we are good.  As soon as I click in the main grid area, it SHOULD transfer the focus back to the main window, but as soon as I click anywhere on the screen(grid or not) it looks like the runtime is essentially hijacking the focus transfer and sending it back to the last active screen.  Focus transfers fine if I click another application(i.e. file explorer)
 


#AcuCobol
#.net
Yeah. It's honestly very weird. I even tried essentially when the user clicks off of the form for it to execute the "cancel" button on the filter form(which transfers focus correctly everytime) and it looks like it transfers the focus correctly, but then immediately transfers the focus to the last active window(i.e. it went down the road I told it to, and then continued down the road that tells it to switch to the other application).

bandicam-2018_2D00_02_2D00_12-08_2D00_48_2D00_28_2D00_183.mp4

 Okay so this might be a little difficult to explain.  Basically we have a cobol screen that has a .net assembly embedded in the screen section. When one of the assemblies functions is activated(which displays another form overlayed on the screen, not another window) the cobol window that had focus loses it's focus, and focus is transferred to last active windows screen that WASN'T controlled by the acucobol runtime(i.e. file explorer). This behavior does not happen when the .net assembly is embedded on a standard windows form outside of the acucobol runtime(i.e. as a simple executable).

We tried switching the .net assembly to run as a stand alone windows form rather than being embedded, but we have a situation where we do not want users to be able to "touch" screens 2 and 3(numbers being screen depth) and the assembly is screen 4.  When the assembly is run, all screens are able to be "touched" whereas before they could not be touched until the old screen 4 was closed.  Not sure if that makes sense, but that is what we are dealing with.  We ARE using a 3rd party control(the assembly is created by us, but the assembly contains other 3rd party dll's), but we can reproduce this behavior without the 3rd party controls.

 

It's a little difficult to see in the video because you can't see the mouse, but I am basically clicking the filter drop down icon(creates new windows form, focus is lost from main window, which is standard behavior).  Nothing happens and we are good.  As soon as I click in the main grid area, it SHOULD transfer the focus back to the main window, but as soon as I click anywhere on the screen(grid or not) it looks like the runtime is essentially hijacking the focus transfer and sending it back to the last active screen.  Focus transfers fine if I click another application(i.e. file explorer)
 


#AcuCobol
#.net
Yeah. It's honestly very weird. I even tried essentially when the user clicks off of the form for it to execute the "cancel" button on the filter form(which transfers focus correctly everytime) and it looks like it transfers the focus correctly, but then immediately transfers the focus to the last active window(i.e. it went down the road I told it to, and then continued down the road that tells it to switch to the other application).
Terms & ConditionsAccessibility statement