Prev: Print to a specific printer
Next: Algorithm of a booking system to turn ON/OFF equipments revisited
From: Charlie on 21 Jun 2010 10:09
(I posted this last Friday, and I recall checking it before I left work, but
it seems to have been gobbled up by the group goblins I guess. Don't know
where it went.)

I'm opening a workbook (visible) and reading a range from a sheet. I'm
leaving the workbook open so the user can make changes. Then they can click
a command button to re-read the range (for error checking).

The problem is that in the compiled version the Excel window wants the focus
after I come back to the VB app window and click the command button. The
Excel button on the taskbar starts flashing orange. Everything works ok, but
it's an annoyance. Clicking on the Excel window, of course, stops the
flashing, but why is it doing this? This is not a problem when running in
the IDE.

In a nutshell:

Set XL = CreateObject("Excel.Application")
XL.Visible = Yes
XL.Workbooks.Open FileName
Grid = GetFromRange( ..., blah, blah)

Is there something I'm doing or not doing that is causing the problem?

Thanks,
Charlie
From: GS on 21 Jun 2010 13:26
Charlie wrote on 6/21/2010 :
> (I posted this last Friday, and I recall checking it before I left work, but
> it seems to have been gobbled up by the group goblins I guess. Don't know
> where it went.)
>
> I'm opening a workbook (visible) and reading a range from a sheet. I'm
> leaving the workbook open so the user can make changes. Then they can click
> a command button to re-read the range (for error checking).
>
> The problem is that in the compiled version the Excel window wants the focus
> after I come back to the VB app window and click the command button. The
> Excel button on the taskbar starts flashing orange. Everything works ok, but
> it's an annoyance. Clicking on the Excel window, of course, stops the
> flashing, but why is it doing this? This is not a problem when running in
> the IDE.
>
> In a nutshell:
>
> Set XL = CreateObject("Excel.Application")
> XL.Visible = Yes
> XL.Workbooks.Open FileName
> Grid = GetFromRange( ..., blah, blah)
>
> Is there something I'm doing or not doing that is causing the problem?
>
> Thanks,
> Charlie

Excel has a property 'UserControl' that should be set TRUE when you
turn control over to the user, and FALSE when your app takes back the
control. Setting XL.Visible = Yes (assuming Yes=True) doesn't hand
control of the instance to the user, even though the user can interact
with the instance since it's visible. (Online docs suggest making your
instance visible sets this property to TRUE)

To give your app's button control without the annoyance, try setting
the prop to FALSE at the beginning of the proc. I don't know for sure
if this will work because I don't switch back and forth like you're
doing here. I normally use a VB6 frontloader to create/setup the
instance and then turn it over to the user because all functionality is
done via a VB6 COMAddin. This allows me to fully control and lock down
Excel's UI however I want, and gives me full VB6 functionality 'in
process' to my instance. Different approach, but I find it a much
better way to go whether my apps are spreadsheet-driven, form-driven,
or a combination of both.

HTH

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc


From: Charlie on 21 Jun 2010 16:48
Thanks for the idea. It didn't work, but I can play around with it some
more. Anyway, users are annoying enough, maybe this is my opportunity to get
even! :0

P.S. yeah, I don't usually do it this way but this inherited app seemed to
fit the mold.

"GS" wrote:

> Charlie wrote on 6/21/2010 :
> > (I posted this last Friday, and I recall checking it before I left work, but
> > it seems to have been gobbled up by the group goblins I guess. Don't know
> > where it went.)
> >
> > I'm opening a workbook (visible) and reading a range from a sheet. I'm
> > leaving the workbook open so the user can make changes. Then they can click
> > a command button to re-read the range (for error checking).
> >
> > The problem is that in the compiled version the Excel window wants the focus
> > after I come back to the VB app window and click the command button. The
> > Excel button on the taskbar starts flashing orange. Everything works ok, but
> > it's an annoyance. Clicking on the Excel window, of course, stops the
> > flashing, but why is it doing this? This is not a problem when running in
> > the IDE.
> >
> > In a nutshell:
> >
> > Set XL = CreateObject("Excel.Application")
> > XL.Visible = Yes
> > XL.Workbooks.Open FileName
> > Grid = GetFromRange( ..., blah, blah)
> >
> > Is there something I'm doing or not doing that is causing the problem?
> >
> > Thanks,
> > Charlie
>
> Excel has a property 'UserControl' that should be set TRUE when you
> turn control over to the user, and FALSE when your app takes back the
> control. Setting XL.Visible = Yes (assuming Yes=True) doesn't hand
> control of the instance to the user, even though the user can interact
> with the instance since it's visible. (Online docs suggest making your
> instance visible sets this property to TRUE)
>
> To give your app's button control without the annoyance, try setting
> the prop to FALSE at the beginning of the proc. I don't know for sure
> if this will work because I don't switch back and forth like you're
> doing here. I normally use a VB6 frontloader to create/setup the
> instance and then turn it over to the user because all functionality is
> done via a VB6 COMAddin. This allows me to fully control and lock down
> Excel's UI however I want, and gives me full VB6 functionality 'in
> process' to my instance. Different approach, but I find it a much
> better way to go whether my apps are spreadsheet-driven, form-driven,
> or a combination of both.
>
> HTH
>
> --
> Garry
>
> Free usenet access at http://www.eternal-september.org
> ClassicVB Users Regroup! comp.lang.basic.visual.misc
>
>
> .
>
 | 
Pages: 1
Prev: Print to a specific printer
Next: Algorithm of a booking system to turn ON/OFF equipments revisited