Window manual re-classing

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Window manual re-classing

Grzegorz Zlotowicz
Hello.
As we know, many controls which don't support Iaccessible interface,
respond to some extend to standard Windows API messages.
After question from one of NVDA users, if we have a function known from
Window-eyes, where user could easilly tell screenreader, that some
unknown control should be treated as listview, or other class of window,
I started to think about it.
Currently, in NVDA even checking if some control responds properly to
winapi messages related to listbox, requires a bit of time, copy and
paste into Python console, and looking into WinApi documentation.
 From the other hand, the task seems simple: providing even most basic
support to common controls through Winapi, and then letting user to
choose what type of control some unknown object is.
It could make many applications currently inaccessible to become usable,
and simplify testing of inaccessible ones, letting easily determine,
that some controls doesn't respond to standard Winapi calls.
My questions:
1. Is somebody working on such thing, and if so, maybe I could help.
2. If nobody works on it, I'm considering it doable, but need feedback
about few things:
- Currently listview and treeview winapi calls are partially implemented
in NvdaObjects, but for example listview32 uses only LVM_GETITEMTEXTW,
so will not work on non-unicode windows.
SysTreeView32 doesn't use the Winapi for retrieving text of item at all.
So would it be better to improve those modules first, and then go
further, or rather starting in a separate add-on, possibly reusing some
already written code?
Separate add-on seems simpler in experiments (can work without running
NVDA from sources), and also there is no possibility of introducing
errors in NVDA itself.
Small disadvantage is code redundancy.
And, in case of successfull implementation, what about integrating it
into NVDA core in future?

Greetings, Greg.


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

Joseph Lee
Hi,
This can be done via app modules and so on by using
chooseNVDAObjectOverlayClasses, but I think this would be handy for some
power users. My main concern is how to expose this to users (perhaps via a
dialog) and if it is desirable to let end users define this sort of thing
(although coders are users, they know (or should know) what they are doing,
hence my mixed feelings).
Cheers,
Joseph

-----Original Message-----
From: Grzegorz Zlotowicz [mailto:[hidden email]]
Sent: Monday, February 29, 2016 11:23 AM
To: [hidden email]
Subject: [Nvda-devel] Window manual re-classing

Hello.
As we know, many controls which don't support Iaccessible interface, respond
to some extend to standard Windows API messages.
After question from one of NVDA users, if we have a function known from
Window-eyes, where user could easilly tell screenreader, that some unknown
control should be treated as listview, or other class of window, I started
to think about it.
Currently, in NVDA even checking if some control responds properly to winapi
messages related to listbox, requires a bit of time, copy and paste into
Python console, and looking into WinApi documentation.
 From the other hand, the task seems simple: providing even most basic
support to common controls through Winapi, and then letting user to choose
what type of control some unknown object is.
It could make many applications currently inaccessible to become usable, and
simplify testing of inaccessible ones, letting easily determine, that some
controls doesn't respond to standard Winapi calls.
My questions:
1. Is somebody working on such thing, and if so, maybe I could help.
2. If nobody works on it, I'm considering it doable, but need feedback about
few things:
- Currently listview and treeview winapi calls are partially implemented in
NvdaObjects, but for example listview32 uses only LVM_GETITEMTEXTW, so will
not work on non-unicode windows.
SysTreeView32 doesn't use the Winapi for retrieving text of item at all.
So would it be better to improve those modules first, and then go further,
or rather starting in a separate add-on, possibly reusing some already
written code?
Separate add-on seems simpler in experiments (can work without running NVDA
from sources), and also there is no possibility of introducing errors in
NVDA itself.
Small disadvantage is code redundancy.
And, in case of successfull implementation, what about integrating it into
NVDA core in future?

Greetings, Greg.


----------------------------------------------------------------------------
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM +
Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor
end-to-end web transactions and take corrective actions now Troubleshoot
faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

Grzegorz Zlotowicz
The appmodule will work in one application only, so I'm thinking about
globalPlugin.
The chooseOverlayClasses method can be defined in globalplugins too.
So a simple dictionary mapping non-standard class name like
"trzcheckbox" to the servicing class like winapiCheckbox, would work and
work globally.
This function has no destructive potential - in worst scenario, some
control could stop responding,
maybe
even whole application could freeze (I didn't manage to cause such
behaviour during my experiments), so there is no risk of giving such
tool to the end user.
In wineyes there was such function too, and nobody was hurt by it.

Greetings, Greg.

W dniu 29.02.2016 21:13, Joseph Lee napisał/a:

> Hi,
> This can be done via app modules and so on by using
> chooseNVDAObjectOverlayClasses, but I think this would be handy for some
> power users. My main concern is how to expose this to users (perhaps via a
> dialog) and if it is desirable to let end users define this sort of thing
> (although coders are users, they know (or should know) what they are doing,
> hence my mixed feelings).
> Cheers,
> Joseph
>
> -----Original Message-----
> From: Grzegorz Zlotowicz [mailto:[hidden email]]
> Sent: Monday, February 29, 2016 11:23 AM
> To: [hidden email]
> Subject: [Nvda-devel] Window manual re-classing
>
> Hello.
> As we know, many controls which don't support Iaccessible interface, respond
> to some extend to standard Windows API messages.
> After question from one of NVDA users, if we have a function known from
> Window-eyes, where user could easilly tell screenreader, that some unknown
> control should be treated as listview, or other class of window, I started
> to think about it.
> Currently, in NVDA even checking if some control responds properly to winapi
> messages related to listbox, requires a bit of time, copy and paste into
> Python console, and looking into WinApi documentation.
>   From the other hand, the task seems simple: providing even most basic
> support to common controls through Winapi, and then letting user to choose
> what type of control some unknown object is.
> It could make many applications currently inaccessible to become usable, and
> simplify testing of inaccessible ones, letting easily determine, that some
> controls doesn't respond to standard Winapi calls.
> My questions:
> 1. Is somebody working on such thing, and if so, maybe I could help.
> 2. If nobody works on it, I'm considering it doable, but need feedback about
> few things:
> - Currently listview and treeview winapi calls are partially implemented in
> NvdaObjects, but for example listview32 uses only LVM_GETITEMTEXTW, so will
> not work on non-unicode windows.
> SysTreeView32 doesn't use the Winapi for retrieving text of item at all.
> So would it be better to improve those modules first, and then go further,
> or rather starting in a separate add-on, possibly reusing some already
> written code?
> Separate add-on seems simpler in experiments (can work without running NVDA
> from sources), and also there is no possibility of introducing errors in
> NVDA itself.
> Small disadvantage is code redundancy.
> And, in case of successfull implementation, what about integrating it into
> NVDA core in future?
>
> Greetings, Greg.
>
>
> ----------------------------------------------------------------------------
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance APM +
> Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor
> end-to-end web transactions and take corrective actions now Troubleshoot
> faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

Joseph Lee
Hi Greg,
Sure, I think a global plugin would suffice, and if there's demand from users and if Mick and Jamie thinks it'll benefit users, then let's add it to the core (perhaps in the future).
Cheers,
Joseph

-----Original Message-----
From: Grzegorz Zlotowicz [mailto:[hidden email]]
Sent: Monday, February 29, 2016 12:51 PM
To: NVDA screen reader development <[hidden email]>
Subject: Re: [Nvda-devel] Window manual re-classing

The appmodule will work in one application only, so I'm thinking about globalPlugin.
The chooseOverlayClasses method can be defined in globalplugins too.
So a simple dictionary mapping non-standard class name like "trzcheckbox" to the servicing class like winapiCheckbox, would work and work globally.
This function has no destructive potential - in worst scenario, some control could stop responding, maybe even whole application could freeze (I didn't manage to cause such behaviour during my experiments), so there is no risk of giving such tool to the end user.
In wineyes there was such function too, and nobody was hurt by it.

Greetings, Greg.

W dniu 29.02.2016 21:13, Joseph Lee napisał/a:

> Hi,
> This can be done via app modules and so on by using
> chooseNVDAObjectOverlayClasses, but I think this would be handy for
> some power users. My main concern is how to expose this to users
> (perhaps via a
> dialog) and if it is desirable to let end users define this sort of
> thing (although coders are users, they know (or should know) what they
> are doing, hence my mixed feelings).
> Cheers,
> Joseph
>
> -----Original Message-----
> From: Grzegorz Zlotowicz [mailto:[hidden email]]
> Sent: Monday, February 29, 2016 11:23 AM
> To: [hidden email]
> Subject: [Nvda-devel] Window manual re-classing
>
> Hello.
> As we know, many controls which don't support Iaccessible interface,
> respond to some extend to standard Windows API messages.
> After question from one of NVDA users, if we have a function known
> from Window-eyes, where user could easilly tell screenreader, that
> some unknown control should be treated as listview, or other class of
> window, I started to think about it.
> Currently, in NVDA even checking if some control responds properly to
> winapi messages related to listbox, requires a bit of time, copy and
> paste into Python console, and looking into WinApi documentation.
>   From the other hand, the task seems simple: providing even most
> basic support to common controls through Winapi, and then letting user
> to choose what type of control some unknown object is.
> It could make many applications currently inaccessible to become
> usable, and simplify testing of inaccessible ones, letting easily
> determine, that some controls doesn't respond to standard Winapi calls.
> My questions:
> 1. Is somebody working on such thing, and if so, maybe I could help.
> 2. If nobody works on it, I'm considering it doable, but need feedback
> about few things:
> - Currently listview and treeview winapi calls are partially
> implemented in NvdaObjects, but for example listview32 uses only
> LVM_GETITEMTEXTW, so will not work on non-unicode windows.
> SysTreeView32 doesn't use the Winapi for retrieving text of item at all.
> So would it be better to improve those modules first, and then go
> further, or rather starting in a separate add-on, possibly reusing
> some already written code?
> Separate add-on seems simpler in experiments (can work without running
> NVDA from sources), and also there is no possibility of introducing
> errors in NVDA itself.
> Small disadvantage is code redundancy.
> And, in case of successfull implementation, what about integrating it
> into NVDA core in future?
>
> Greetings, Greg.
>
>
> ----------------------------------------------------------------------
> ------
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>
> ----------------------------------------------------------------------
> --------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

James Teh
In reply to this post by Grzegorz Zlotowicz
Hi.
NVDA doesn't provide its own Win32 control implementations because
normally, it gets this information through MSAA, UIA or IA2. Fr these
cases, we absolutely don't want to use our own complete Win32 API
implementation because we would miss out on additional information
provided via the accessibility APIs. For example, it's possible to
change the name exposed for a button using MSAA dynamic annotation. We
do implement special Win32 API support where we need information beyond
what accessibility APIs provide; e.g. the columns in list views.

On the other hand,  there are certainly apps which subclass these
controls and don't set things up properly to work with the standard
accessibility implementations. In these cases, a Win32 API
implementation would be helpful. I personally have my doubts about how
often this actually occurs. How often does reclassing of controls other
than those with just a label (e.g. buttons) actually work?

The key point here is that we certainly don't want to use these by
default for the standard controls. We'd only use them where broken
subclassing occurred. That does mean you'll need separate classes,
though, since you'll need a *full* implementation, not partial as we
have now.

All of that said, I'm not against having a separate module in
NVDAObjects containing these implementations.

I still don't feel it is necessary for these to be exposed to end users
via a GUI, at least not in core. The existing
chooseNVDAObjectOverlayClasses method will serve well enough. People
wanting to mess with this still need to have decent technical knowledge,
so I don't think this is unreasonable. I guess an add-on could provide a
GUI for quick testing if that's what people want. Perhaps this GUI could
allow a user to press a button to "probe" a control to see what messages
it supports.

Jamie

On 1/03/2016 5:23 AM, Grzegorz Zlotowicz wrote:

> Hello.
> As we know, many controls which don't support Iaccessible interface,
> respond to some extend to standard Windows API messages.
> After question from one of NVDA users, if we have a function known from
> Window-eyes, where user could easilly tell screenreader, that some
> unknown control should be treated as listview, or other class of window,
> I started to think about it.
> Currently, in NVDA even checking if some control responds properly to
> winapi messages related to listbox, requires a bit of time, copy and
> paste into Python console, and looking into WinApi documentation.
>   From the other hand, the task seems simple: providing even most basic
> support to common controls through Winapi, and then letting user to
> choose what type of control some unknown object is.
> It could make many applications currently inaccessible to become usable,
> and simplify testing of inaccessible ones, letting easily determine,
> that some controls doesn't respond to standard Winapi calls.
> My questions:
> 1. Is somebody working on such thing, and if so, maybe I could help.
> 2. If nobody works on it, I'm considering it doable, but need feedback
> about few things:
> - Currently listview and treeview winapi calls are partially implemented
> in NvdaObjects, but for example listview32 uses only LVM_GETITEMTEXTW,
> so will not work on non-unicode windows.
> SysTreeView32 doesn't use the Winapi for retrieving text of item at all.
> So would it be better to improve those modules first, and then go
> further, or rather starting in a separate add-on, possibly reusing some
> already written code?
> Separate add-on seems simpler in experiments (can work without running
> NVDA from sources), and also there is no possibility of introducing
> errors in NVDA itself.
> Small disadvantage is code redundancy.
> And, in case of successfull implementation, what about integrating it
> into NVDA core in future?
>
> Greetings, Greg.
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

John Isige
Do people really need some technical knowledge? I got a program working
by reclassing a window as terminal, and I basically did that by grabbing
the code for PuTTY and stealing it. That's not exactly rocket science,
and now the thing works where it didn't before.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

mk360
+1. I'm not a programer but I used things like these only with test and
test and test...

El 29/02/2016 a las 20:06, John Schucker escribió:

> Do people really need some technical knowledge? I got a program working
> by reclassing a window as terminal, and I basically did that by grabbing
> the code for PuTTY and stealing it. That's not exactly rocket science,
> and now the thing works where it didn't before.
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

James Teh
In reply to this post by John Isige
My point was that we don't need a separate GUI for this. As you've just
pointed out, you were able to achieve it with little to no NVDA
development knowledge.

On 1/03/2016 9:06 AM, John Schucker wrote:

> Do people really need some technical knowledge? I got a program working
> by reclassing a window as terminal, and I basically did that by grabbing
> the code for PuTTY and stealing it. That's not exactly rocket science,
> and now the thing works where it didn't before.
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

Doug Lee
In reply to this post by James Teh
My BX package for JAWS has the aims of supporting this sort of control probing and also of allowing me to test
the JAWS functions provided in the scripting language. The latter would not be so necessary for NVDA since
Python is a full programming language, though testing the NVDA support for things could be useful. But probing
controls quickly is a key element of developing good scripts, addons, etc., according to my experience doing
this for so long.

So in my view, the point of such an addon would be to help addon developers make wise and effective choices
for how to get things to work in irregular situations.

On Tue, Mar 01, 2016 at 08:28:09AM +1000, James Teh wrote:
Hi.
NVDA doesn't provide its own Win32 control implementations because
normally, it gets this information through MSAA, UIA or IA2. Fr these
cases, we absolutely don't want to use our own complete Win32 API
implementation because we would miss out on additional information
provided via the accessibility APIs. For example, it's possible to
change the name exposed for a button using MSAA dynamic annotation. We
do implement special Win32 API support where we need information beyond
what accessibility APIs provide; e.g. the columns in list views.

On the other hand,  there are certainly apps which subclass these
controls and don't set things up properly to work with the standard
accessibility implementations. In these cases, a Win32 API
implementation would be helpful. I personally have my doubts about how
often this actually occurs. How often does reclassing of controls other
than those with just a label (e.g. buttons) actually work?

The key point here is that we certainly don't want to use these by
default for the standard controls. We'd only use them where broken
subclassing occurred. That does mean you'll need separate classes,
though, since you'll need a *full* implementation, not partial as we
have now.

All of that said, I'm not against having a separate module in
NVDAObjects containing these implementations.

I still don't feel it is necessary for these to be exposed to end users
via a GUI, at least not in core. The existing
chooseNVDAObjectOverlayClasses method will serve well enough. People
wanting to mess with this still need to have decent technical knowledge,
so I don't think this is unreasonable. I guess an add-on could provide a
GUI for quick testing if that's what people want. Perhaps this GUI could
allow a user to press a button to "probe" a control to see what messages
it supports.

Jamie

On 1/03/2016 5:23 AM, Grzegorz Zlotowicz wrote:

> Hello.
> As we know, many controls which don't support Iaccessible interface,
> respond to some extend to standard Windows API messages.
> After question from one of NVDA users, if we have a function known from
> Window-eyes, where user could easilly tell screenreader, that some
> unknown control should be treated as listview, or other class of window,
> I started to think about it.
> Currently, in NVDA even checking if some control responds properly to
> winapi messages related to listbox, requires a bit of time, copy and
> paste into Python console, and looking into WinApi documentation.
>   From the other hand, the task seems simple: providing even most basic
> support to common controls through Winapi, and then letting user to
> choose what type of control some unknown object is.
> It could make many applications currently inaccessible to become usable,
> and simplify testing of inaccessible ones, letting easily determine,
> that some controls doesn't respond to standard Winapi calls.
> My questions:
> 1. Is somebody working on such thing, and if so, maybe I could help.
> 2. If nobody works on it, I'm considering it doable, but need feedback
> about few things:
> - Currently listview and treeview winapi calls are partially implemented
> in NvdaObjects, but for example listview32 uses only LVM_GETITEMTEXTW,
> so will not work on non-unicode windows.
> SysTreeView32 doesn't use the Winapi for retrieving text of item at all.
> So would it be better to improve those modules first, and then go
> further, or rather starting in a separate add-on, possibly reusing some
> already written code?
> Separate add-on seems simpler in experiments (can work without running
> NVDA from sources), and also there is no possibility of introducing
> errors in NVDA itself.
> Small disadvantage is code redundancy.
> And, in case of successfull implementation, what about integrating it
> into NVDA core in future?
>
> Greetings, Greg.
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

--
Doug Lee                 [hidden email]                http://www.dlee.org
SSB BART Group           [hidden email]   http://www.ssbbartgroup.com
"Pray devoutly, but hammer stoutly."
--Sir William G. Benham

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

Grzegorz Zlotowicz
In reply to this post by James Teh
Hi and thanks to all for opinions.
As I mentioned, testing unknown control using console, and then making
it to respond if it's a WinApi-answering control, is very time consuming.
So we all agree, that programming maybe even most basic support of such
controls using raw WinApi, can be helpful.
Then, let's say we have a unknown control which class is treeview20wndclass.
Possibility 1:
write an nvda-addon, which simply inserts earlier defined winapi
treeview class into the overlay classes of such object.
It would take few minutes, and is unavailable for non-technical users
who doesn't know Python at all, and aren't so adventurous to do
something in the NVDA folder.
After this time, it can come out, that in fact this treeview doesn't
support winapi.
Second variant: on the unknown control user presses nvda+shift+c, and
dialogbox pops up having title "reclass window treeview20wndclass".
In this dialog user has simple list of possible raw winapi classes.
He is not a programmer, and not technically skilled person at all, but
knows that if the title contains word "treeview20wndclass" and one of
the item in the list is "treeview", it's definetely worth checking it.
So it's 3 A.m. in small town somewhere at the end of the world, where
our non-technical and non-adventurous user lives, trying to get some
non-mainstream application to work for him.
He selects treeview, presses OK, and tadaam, it works!
No add-on writing, no fear of spoiling NVDA, and just 10 seconds of
activity.
Of course it's possible, that NVDA will no respond in this window, and
that the application crashes after receiving tvm_getitem message, but it
simply will mean, that this particular control is no so easy to service,
and user from our example would have (in worst scenario) to restart the
app, and try an other thing.

After all, having a winapi support for common controls programmed, doing
such simple dialog and dictionary of class mappings to the raw winapi
classes, seems trivial.

Greetings, Greg.

W dniu 01.03.2016 03:29, James Teh napisał/a:

> My point was that we don't need a separate GUI for this. As you've just
> pointed out, you were able to achieve it with little to no NVDA
> development knowledge.
>
> On 1/03/2016 9:06 AM, John Schucker wrote:
>> Do people really need some technical knowledge? I got a program working
>> by reclassing a window as terminal, and I basically did that by grabbing
>> the code for PuTTY and stealing it. That's not exactly rocket science,
>> and now the thing works where it didn't before.
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>> _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

James Teh
Of course, add-ons can do whatever they like; that's the whole point of
add-ons. However, here are the reasons I don't want to include a user
exposed UI like this into core:
1. Doing anything like this does require at least some very basic
technical knowledge. Even the whole idea of "class names" is technical.
If you expose something like this to users, users need to be able to
understand it.
2. If you have something like this, there is an expectation of success.
There are many different reasons this might not work (see below), but
explaining those to a user is hard. It's very hard to document something
for non-technical users when there is a high chance of failure.
3. This high chance of failure creates a support burden for us. When it
doesn't work, users are likely to ask for help or report that it doesn't
work in this or that situation.
4. You're assuming that the majority of custom controls out there are
subclassed Win32 controls. Even when controls have their own window (see
below), in all my years of working in this field, I've seen very few
cases where this kind of reclassing actually works well.
5. A lot of custom controls which have their own window have the same
class name as other controls. This is becoming more and more common.
Consider useless class names like "DirectUIHWND". In this case, there is
a risk that someone will reclass and be confused as to why a whole lot
of other controls in that app suddenly stop working.
6. Also more and more common in modern apps is sharing the same window
for multiple controls. In fact, quite a few apps now have a single
window and draw all of their controls into that window. Same risk as
point 5.

Imagine trying to document all of these possibilities in a way users can
understand. Remember, whenever we include a user exposed feature into
NVDA, it must be thoroughly documented. I can't even begin to imagine
thoroughly documenting this.

Jamie

On 2/03/2016 7:59 AM, Grzegorz Zlotowicz wrote:

> Hi and thanks to all for opinions.
> As I mentioned, testing unknown control using console, and then making
> it to respond if it's a WinApi-answering control, is very time consuming.
> So we all agree, that programming maybe even most basic support of such
> controls using raw WinApi, can be helpful.
> Then, let's say we have a unknown control which class is treeview20wndclass.
> Possibility 1:
> write an nvda-addon, which simply inserts earlier defined winapi
> treeview class into the overlay classes of such object.
> It would take few minutes, and is unavailable for non-technical users
> who doesn't know Python at all, and aren't so adventurous to do
> something in the NVDA folder.
> After this time, it can come out, that in fact this treeview doesn't
> support winapi.
> Second variant: on the unknown control user presses nvda+shift+c, and
> dialogbox pops up having title "reclass window treeview20wndclass".
> In this dialog user has simple list of possible raw winapi classes.
> He is not a programmer, and not technically skilled person at all, but
> knows that if the title contains word "treeview20wndclass" and one of
> the item in the list is "treeview", it's definetely worth checking it.
> So it's 3 A.m. in small town somewhere at the end of the world, where
> our non-technical and non-adventurous user lives, trying to get some
> non-mainstream application to work for him.
> He selects treeview, presses OK, and tadaam, it works!
> No add-on writing, no fear of spoiling NVDA, and just 10 seconds of
> activity.
> Of course it's possible, that NVDA will no respond in this window, and
> that the application crashes after receiving tvm_getitem message, but it
> simply will mean, that this particular control is no so easy to service,
> and user from our example would have (in worst scenario) to restart the
> app, and try an other thing.
>
> After all, having a winapi support for common controls programmed, doing
> such simple dialog and dictionary of class mappings to the raw winapi
> classes, seems trivial.
>
> Greetings, Greg.
>
> W dniu 01.03.2016 03:29, James Teh napisał/a:
>> My point was that we don't need a separate GUI for this. As you've just
>> pointed out, you were able to achieve it with little to no NVDA
>> development knowledge.
>>
>> On 1/03/2016 9:06 AM, John Schucker wrote:
>>> Do people really need some technical knowledge? I got a program working
>>> by reclassing a window as terminal, and I basically did that by grabbing
>>> the code for PuTTY and stealing it. That's not exactly rocket science,
>>> and now the thing works where it didn't before.
>>>
>>> ------------------------------------------------------------------------------
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>> _______________________________________________
>>> Nvda-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

Brian Gaff Lineone downstairs
I'd agree about this one. Unless you make an experts only way into this. I
can recall when Dolphin attempted to make a more detailed system to
configure their reader to work with difficult apps, the multiple choices and
heaps of property sheets tended to put one off before you even started, and
that was before all the different ways increased as they have more recently,
and of course nobody can know what is about to come out that might cause
problems you had not even considered.

 I looked at some of the docs on accessability and it is a minefield its a
wonder things work as well as they do sometimes.


Brian

[hidden email]
Brian Gaff's other account.

----- Original Message -----
From: "James Teh" <[hidden email]>
To: "NVDA screen reader development" <[hidden email]>
Sent: Tuesday, March 01, 2016 11:01 PM
Subject: Re: [Nvda-devel] Window manual re-classing


> Of course, add-ons can do whatever they like; that's the whole point of
> add-ons. However, here are the reasons I don't want to include a user
> exposed UI like this into core:
> 1. Doing anything like this does require at least some very basic
> technical knowledge. Even the whole idea of "class names" is technical.
> If you expose something like this to users, users need to be able to
> understand it.
> 2. If you have something like this, there is an expectation of success.
> There are many different reasons this might not work (see below), but
> explaining those to a user is hard. It's very hard to document something
> for non-technical users when there is a high chance of failure.
> 3. This high chance of failure creates a support burden for us. When it
> doesn't work, users are likely to ask for help or report that it doesn't
> work in this or that situation.
> 4. You're assuming that the majority of custom controls out there are
> subclassed Win32 controls. Even when controls have their own window (see
> below), in all my years of working in this field, I've seen very few
> cases where this kind of reclassing actually works well.
> 5. A lot of custom controls which have their own window have the same
> class name as other controls. This is becoming more and more common.
> Consider useless class names like "DirectUIHWND". In this case, there is
> a risk that someone will reclass and be confused as to why a whole lot
> of other controls in that app suddenly stop working.
> 6. Also more and more common in modern apps is sharing the same window
> for multiple controls. In fact, quite a few apps now have a single
> window and draw all of their controls into that window. Same risk as
> point 5.
>
> Imagine trying to document all of these possibilities in a way users can
> understand. Remember, whenever we include a user exposed feature into
> NVDA, it must be thoroughly documented. I can't even begin to imagine
> thoroughly documenting this.
>
> Jamie
>
> On 2/03/2016 7:59 AM, Grzegorz Zlotowicz wrote:
>> Hi and thanks to all for opinions.
>> As I mentioned, testing unknown control using console, and then making
>> it to respond if it's a WinApi-answering control, is very time consuming.
>> So we all agree, that programming maybe even most basic support of such
>> controls using raw WinApi, can be helpful.
>> Then, let's say we have a unknown control which class is
>> treeview20wndclass.
>> Possibility 1:
>> write an nvda-addon, which simply inserts earlier defined winapi
>> treeview class into the overlay classes of such object.
>> It would take few minutes, and is unavailable for non-technical users
>> who doesn't know Python at all, and aren't so adventurous to do
>> something in the NVDA folder.
>> After this time, it can come out, that in fact this treeview doesn't
>> support winapi.
>> Second variant: on the unknown control user presses nvda+shift+c, and
>> dialogbox pops up having title "reclass window treeview20wndclass".
>> In this dialog user has simple list of possible raw winapi classes.
>> He is not a programmer, and not technically skilled person at all, but
>> knows that if the title contains word "treeview20wndclass" and one of
>> the item in the list is "treeview", it's definetely worth checking it.
>> So it's 3 A.m. in small town somewhere at the end of the world, where
>> our non-technical and non-adventurous user lives, trying to get some
>> non-mainstream application to work for him.
>> He selects treeview, presses OK, and tadaam, it works!
>> No add-on writing, no fear of spoiling NVDA, and just 10 seconds of
>> activity.
>> Of course it's possible, that NVDA will no respond in this window, and
>> that the application crashes after receiving tvm_getitem message, but it
>> simply will mean, that this particular control is no so easy to service,
>> and user from our example would have (in worst scenario) to restart the
>> app, and try an other thing.
>>
>> After all, having a winapi support for common controls programmed, doing
>> such simple dialog and dictionary of class mappings to the raw winapi
>> classes, seems trivial.
>>
>> Greetings, Greg.
>>
>> W dniu 01.03.2016 03:29, James Teh napisał/a:
>>> My point was that we don't need a separate GUI for this. As you've just
>>> pointed out, you were able to achieve it with little to no NVDA
>>> development knowledge.
>>>
>>> On 1/03/2016 9:06 AM, John Schucker wrote:
>>>> Do people really need some technical knowledge? I got a program working
>>>> by reclassing a window as terminal, and I basically did that by
>>>> grabbing
>>>> the code for PuTTY and stealing it. That's not exactly rocket science,
>>>> and now the thing works where it didn't before.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>> Monitor end-to-end web transactions and take corrective actions now
>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>> _______________________________________________
>>>> Nvda-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>> _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: [hidden email]
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

Pete
In reply to this post by James Teh

   an option to e-mail the maker of the application with the in
accessible control to ask for assistance with it might be better. That
way the developer of the app would get a lot of requests for help with
it and may decide to help, or not?
   Pete


On 3/1/2016 6:01 PM, James The wrote:

> Of course, add-ons can do whatever they like; that's the whole point of
> add-ons. However, here are the reasons I don't want to include a user
> exposed UI like this into core:
> 1. Doing anything like this does require at least some very basic
> technical knowledge. Even the whole idea of "class names" is technical.
> If you expose something like this to users, users need to be able to
> understand it.
> 2. If you have something like this, there is an expectation of success.
> There are many different reasons this might not work (see below), but
> explaining those to a user is hard. It's very hard to document something
> for non-technical users when there is a high chance of failure.
> 3. This high chance of failure creates a support burden for us. When it
> doesn't work, users are likely to ask for help or report that it doesn't
> work in this or that situation.
> 4. You're assuming that the majority of custom controls out there are
> subclassed Win32 controls. Even when controls have their own window (see
> below), in all my years of working in this field, I've seen very few
> cases where this kind of reclassing actually works well.
> 5. A lot of custom controls which have their own window have the same
> class name as other controls. This is becoming more and more common.
> Consider useless class names like "DirectUIHWND". In this case, there is
> a risk that someone will reclass and be confused as to why a whole lot
> of other controls in that app suddenly stop working.
> 6. Also more and more common in modern apps is sharing the same window
> for multiple controls. In fact, quite a few apps now have a single
> window and draw all of their controls into that window. Same risk as
> point 5.
>
> Imagine trying to document all of these possibilities in a way users can
> understand. Remember, whenever we include a user exposed feature into
> NVDA, it must be thoroughly documented. I can't even begin to imagine
> thoroughly documenting this.
>
> Jamie
>
> On 2/03/2016 7:59 AM, Grzegorz Zlotowicz wrote:
>> Hi and thanks to all for opinions.
>> As I mentioned, testing unknown control using console, and then making
>> it to respond if it's a WinApi-answering control, is very time consuming.
>> So we all agree, that programming maybe even most basic support of such
>> controls using raw WinApi, can be helpful.
>> Then, let's say we have a unknown control which class is treeview20wndclass.
>> Possibility 1:
>> write an nvda-addon, which simply inserts earlier defined winapi
>> treeview class into the overlay classes of such object.
>> It would take few minutes, and is unavailable for non-technical users
>> who doesn't know Python at all, and aren't so adventurous to do
>> something in the NVDA folder.
>> After this time, it can come out, that in fact this treeview doesn't
>> support winapi.
>> Second variant: on the unknown control user presses nvda+shift+c, and
>> dialogbox pops up having title "reclass window treeview20wndclass".
>> In this dialog user has simple list of possible raw winapi classes.
>> He is not a programmer, and not technically skilled person at all, but
>> knows that if the title contains word "treeview20wndclass" and one of
>> the item in the list is "treeview", it's definetely worth checking it.
>> So it's 3 A.m. in small town somewhere at the end of the world, where
>> our non-technical and non-adventurous user lives, trying to get some
>> non-mainstream application to work for him.
>> He selects treeview, presses OK, and tadaam, it works!
>> No add-on writing, no fear of spoiling NVDA, and just 10 seconds of
>> activity.
>> Of course it's possible, that NVDA will no respond in this window, and
>> that the application crashes after receiving tvm_getitem message, but it
>> simply will mean, that this particular control is no so easy to service,
>> and user from our example would have (in worst scenario) to restart the
>> app, and try an other thing.
>>
>> After all, having a winapi support for common controls programmed, doing
>> such simple dialog and dictionary of class mappings to the raw winapi
>> classes, seems trivial.
>>
>> Greetings, Greg.
>>
>> W dniu 01.03.2016 03:29, James Teh napisał/a:
>>> My point was that we don't need a separate GUI for this. As you've just
>>> pointed out, you were able to achieve it with little to no NVDA
>>> development knowledge.
>>>
>>> On 1/03/2016 9:06 AM, John Schucker wrote:
>>>> Do people really need some technical knowledge? I got a program working
>>>> by reclassing a window as terminal, and I basically did that by grabbing
>>>> the code for PuTTY and stealing it. That's not exactly rocket science,
>>>> and now the thing works where it didn't before.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>> Monitor end-to-end web transactions and take corrective actions now
>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>> _______________________________________________
>>>> Nvda-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>> _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

option for nvda

Pete

   A cordial invitation to developers of applications to join the nvda
development list might be better than an e-mail requesting assistance,
or may be both ask for assistance and invite to join the development list.
So ideas of accessing the controls may be initiated.  May be more ideas
will help?
   I think exposing the developers of applications to what is needed by
nvda and other screen readers is a good thing, in this way the
developers may start thinking more about the kinds of people wanting
access to their software, and what is required for accessible controls.
   Thanks!
   Pete


On 3/2/2016 11:30 AM, Pete wrote:

>     an option to e-mail the maker of the application with the in
> accessible control to ask for assistance with it might be better. That
> way the developer of the app would get a lot of requests for help with
> it and may decide to help, or not?
>     Pete
>
>
> On 3/1/2016 6:01 PM, James The wrote:
>> Of course, add-ons can do whatever they like; that's the whole point of
>> add-ons. However, here are the reasons I don't want to include a user
>> exposed UI like this into core:
>> 1. Doing anything like this does require at least some very basic
>> technical knowledge. Even the whole idea of "class names" is technical.
>> If you expose something like this to users, users need to be able to
>> understand it.
>> 2. If you have something like this, there is an expectation of success.
>> There are many different reasons this might not work (see below), but
>> explaining those to a user is hard. It's very hard to document something
>> for non-technical users when there is a high chance of failure.
>> 3. This high chance of failure creates a support burden for us. When it
>> doesn't work, users are likely to ask for help or report that it doesn't
>> work in this or that situation.
>> 4. You're assuming that the majority of custom controls out there are
>> subclassed Win32 controls. Even when controls have their own window (see
>> below), in all my years of working in this field, I've seen very few
>> cases where this kind of reclassing actually works well.
>> 5. A lot of custom controls which have their own window have the same
>> class name as other controls. This is becoming more and more common.
>> Consider useless class names like "DirectUIHWND". In this case, there is
>> a risk that someone will reclass and be confused as to why a whole lot
>> of other controls in that app suddenly stop working.
>> 6. Also more and more common in modern apps is sharing the same window
>> for multiple controls. In fact, quite a few apps now have a single
>> window and draw all of their controls into that window. Same risk as
>> point 5.
>>
>> Imagine trying to document all of these possibilities in a way users can
>> understand. Remember, whenever we include a user exposed feature into
>> NVDA, it must be thoroughly documented. I can't even begin to imagine
>> thoroughly documenting this.
>>
>> Jamie
>>
>> On 2/03/2016 7:59 AM, Grzegorz Zlotowicz wrote:
>>> Hi and thanks to all for opinions.
>>> As I mentioned, testing unknown control using console, and then making
>>> it to respond if it's a WinApi-answering control, is very time consuming.
>>> So we all agree, that programming maybe even most basic support of such
>>> controls using raw WinApi, can be helpful.
>>> Then, let's say we have a unknown control which class is treeview20wndclass.
>>> Possibility 1:
>>> write an nvda-addon, which simply inserts earlier defined winapi
>>> treeview class into the overlay classes of such object.
>>> It would take few minutes, and is unavailable for non-technical users
>>> who doesn't know Python at all, and aren't so adventurous to do
>>> something in the NVDA folder.
>>> After this time, it can come out, that in fact this treeview doesn't
>>> support winapi.
>>> Second variant: on the unknown control user presses nvda+shift+c, and
>>> dialogbox pops up having title "reclass window treeview20wndclass".
>>> In this dialog user has simple list of possible raw winapi classes.
>>> He is not a programmer, and not technically skilled person at all, but
>>> knows that if the title contains word "treeview20wndclass" and one of
>>> the item in the list is "treeview", it's definetely worth checking it.
>>> So it's 3 A.m. in small town somewhere at the end of the world, where
>>> our non-technical and non-adventurous user lives, trying to get some
>>> non-mainstream application to work for him.
>>> He selects treeview, presses OK, and tadaam, it works!
>>> No add-on writing, no fear of spoiling NVDA, and just 10 seconds of
>>> activity.
>>> Of course it's possible, that NVDA will no respond in this window, and
>>> that the application crashes after receiving tvm_getitem message, but it
>>> simply will mean, that this particular control is no so easy to service,
>>> and user from our example would have (in worst scenario) to restart the
>>> app, and try an other thing.
>>>
>>> After all, having a winapi support for common controls programmed, doing
>>> such simple dialog and dictionary of class mappings to the raw winapi
>>> classes, seems trivial.
>>>
>>> Greetings, Greg.
>>>
>>> W dniu 01.03.2016 03:29, James Teh napisał/a:
>>>> My point was that we don't need a separate GUI for this. As you've just
>>>> pointed out, you were able to achieve it with little to no NVDA
>>>> development knowledge.
>>>>
>>>> On 1/03/2016 9:06 AM, John Schucker wrote:
>>>>> Do people really need some technical knowledge? I got a program working
>>>>> by reclassing a window as terminal, and I basically did that by grabbing
>>>>> the code for PuTTY and stealing it. That's not exactly rocket science,
>>>>> and now the thing works where it didn't before.
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>>> Monitor end-to-end web transactions and take corrective actions now
>>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>>> _______________________________________________
>>>>> Nvda-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>> ------------------------------------------------------------------------------
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>> _______________________________________________
>>> Nvda-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: option for nvda

Joseph Lee
Hi Pete,
I was about to suggest a slightly related thing: the NVDACon planning committee does plan to offer a chance for sighted developers to talk to NVDA developers in hopes of exchanging ideas, accessibility references and tips and so forth. Inviting these developers to this list could be a good start for discussions like this.
Cheers,
Joseph

-----Original Message-----
From: Pete [mailto:[hidden email]]
Sent: Wednesday, March 2, 2016 10:25 AM
To: NVDA screen reader development <[hidden email]>
Subject: [Nvda-devel] option for nvda


   A cordial invitation to developers of applications to join the nvda development list might be better than an e-mail requesting assistance, or may be both ask for assistance and invite to join the development list.
So ideas of accessing the controls may be initiated.  May be more ideas will help?
   I think exposing the developers of applications to what is needed by nvda and other screen readers is a good thing, in this way the developers may start thinking more about the kinds of people wanting access to their software, and what is required for accessible controls.
   Thanks!
   Pete


On 3/2/2016 11:30 AM, Pete wrote:

>     an option to e-mail the maker of the application with the in
> accessible control to ask for assistance with it might be better. That
> way the developer of the app would get a lot of requests for help with
> it and may decide to help, or not?
>     Pete
>
>
> On 3/1/2016 6:01 PM, James The wrote:
>> Of course, add-ons can do whatever they like; that's the whole point
>> of add-ons. However, here are the reasons I don't want to include a
>> user exposed UI like this into core:
>> 1. Doing anything like this does require at least some very basic
>> technical knowledge. Even the whole idea of "class names" is technical.
>> If you expose something like this to users, users need to be able to
>> understand it.
>> 2. If you have something like this, there is an expectation of success.
>> There are many different reasons this might not work (see below), but
>> explaining those to a user is hard. It's very hard to document
>> something for non-technical users when there is a high chance of failure.
>> 3. This high chance of failure creates a support burden for us. When
>> it doesn't work, users are likely to ask for help or report that it
>> doesn't work in this or that situation.
>> 4. You're assuming that the majority of custom controls out there are
>> subclassed Win32 controls. Even when controls have their own window
>> (see below), in all my years of working in this field, I've seen very
>> few cases where this kind of reclassing actually works well.
>> 5. A lot of custom controls which have their own window have the same
>> class name as other controls. This is becoming more and more common.
>> Consider useless class names like "DirectUIHWND". In this case, there
>> is a risk that someone will reclass and be confused as to why a whole
>> lot of other controls in that app suddenly stop working.
>> 6. Also more and more common in modern apps is sharing the same
>> window for multiple controls. In fact, quite a few apps now have a
>> single window and draw all of their controls into that window. Same
>> risk as point 5.
>>
>> Imagine trying to document all of these possibilities in a way users
>> can understand. Remember, whenever we include a user exposed feature
>> into NVDA, it must be thoroughly documented. I can't even begin to
>> imagine thoroughly documenting this.
>>
>> Jamie
>>
>> On 2/03/2016 7:59 AM, Grzegorz Zlotowicz wrote:
>>> Hi and thanks to all for opinions.
>>> As I mentioned, testing unknown control using console, and then
>>> making it to respond if it's a WinApi-answering control, is very time consuming.
>>> So we all agree, that programming maybe even most basic support of
>>> such controls using raw WinApi, can be helpful.
>>> Then, let's say we have a unknown control which class is treeview20wndclass.
>>> Possibility 1:
>>> write an nvda-addon, which simply inserts earlier defined winapi
>>> treeview class into the overlay classes of such object.
>>> It would take few minutes, and is unavailable for non-technical
>>> users who doesn't know Python at all, and aren't so adventurous to
>>> do something in the NVDA folder.
>>> After this time, it can come out, that in fact this treeview doesn't
>>> support winapi.
>>> Second variant: on the unknown control user presses nvda+shift+c,
>>> and dialogbox pops up having title "reclass window treeview20wndclass".
>>> In this dialog user has simple list of possible raw winapi classes.
>>> He is not a programmer, and not technically skilled person at all,
>>> but knows that if the title contains word "treeview20wndclass" and
>>> one of the item in the list is "treeview", it's definetely worth checking it.
>>> So it's 3 A.m. in small town somewhere at the end of the world,
>>> where our non-technical and non-adventurous user lives, trying to
>>> get some non-mainstream application to work for him.
>>> He selects treeview, presses OK, and tadaam, it works!
>>> No add-on writing, no fear of spoiling NVDA, and just 10 seconds of
>>> activity.
>>> Of course it's possible, that NVDA will no respond in this window,
>>> and that the application crashes after receiving tvm_getitem
>>> message, but it simply will mean, that this particular control is no
>>> so easy to service, and user from our example would have (in worst
>>> scenario) to restart the app, and try an other thing.
>>>
>>> After all, having a winapi support for common controls programmed,
>>> doing such simple dialog and dictionary of class mappings to the raw
>>> winapi classes, seems trivial.
>>>
>>> Greetings, Greg.
>>>
>>> W dniu 01.03.2016 03:29, James Teh napisał/a:
>>>> My point was that we don't need a separate GUI for this. As you've
>>>> just pointed out, you were able to achieve it with little to no
>>>> NVDA development knowledge.
>>>>
>>>> On 1/03/2016 9:06 AM, John Schucker wrote:
>>>>> Do people really need some technical knowledge? I got a program
>>>>> working by reclassing a window as terminal, and I basically did
>>>>> that by grabbing the code for PuTTY and stealing it. That's not
>>>>> exactly rocket science, and now the thing works where it didn't before.
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ------------
>>>>> Site24x7 APM Insight: Get Deep Visibility into Application
>>>>> Performance APM + Mobile APM + RUM: Monitor 3 App instances at
>>>>> just $35/Month Monitor end-to-end web transactions and take
>>>>> corrective actions now Troubleshoot faster and improve end-user experience. Signup Now!
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>>> _______________________________________________
>>>>> Nvda-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>> --------------------------------------------------------------------
>>> ----------
>>> Site24x7 APM Insight: Get Deep Visibility into Application
>>> Performance APM + Mobile APM + RUM: Monitor 3 App instances at just
>>> $35/Month Monitor end-to-end web transactions and take corrective
>>> actions now Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>> _______________________________________________
>>> Nvda-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
> ----------------------------------------------------------------------
> --------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: option for nvda

Pete

   Hi  Joseph
   I am glad you agree some thing like this is a good thing! Hopefully
it will become a reality soon.
   Thanks!
   Pete


On 3/2/2016 1:31 PM, Joseph Lee wrote:

> Hi Pete,
> I was about to suggest a slightly related thing: the NVDACon planning committee does plan to offer a chance for sighted developers to talk to NVDA developers in hopes of exchanging ideas, accessibility references and tips and so forth. Inviting these developers to this list could be a good start for discussions like this.
> Cheers,
> Joseph
>
> -----Original Message-----
> From: Pete [mailto:[hidden email]]
> Sent: Wednesday, March 2, 2016 10:25 AM
> To: NVDA screen reader development <[hidden email]>
> Subject: [Nvda-devel] option for nvda
>
>
>     A cordial invitation to developers of applications to join the nvda development list might be better than an e-mail requesting assistance, or may be both ask for assistance and invite to join the development list.
> So ideas of accessing the controls may be initiated.  May be more ideas will help?
>     I think exposing the developers of applications to what is needed by nvda and other screen readers is a good thing, in this way the developers may start thinking more about the kinds of people wanting access to their software, and what is required for accessible controls.
>     Thanks!
>     Pete
>
>
> On 3/2/2016 11:30 AM, Pete wrote:
>>      an option to e-mail the maker of the application with the in
>> accessible control to ask for assistance with it might be better. That
>> way the developer of the app would get a lot of requests for help with
>> it and may decide to help, or not?
>>      Pete
>>
>>
>> On 3/1/2016 6:01 PM, James The wrote:
>>> Of course, add-ons can do whatever they like; that's the whole point
>>> of add-ons. However, here are the reasons I don't want to include a
>>> user exposed UI like this into core:
>>> 1. Doing anything like this does require at least some very basic
>>> technical knowledge. Even the whole idea of "class names" is technical.
>>> If you expose something like this to users, users need to be able to
>>> understand it.
>>> 2. If you have something like this, there is an expectation of success.
>>> There are many different reasons this might not work (see below), but
>>> explaining those to a user is hard. It's very hard to document
>>> something for non-technical users when there is a high chance of failure.
>>> 3. This high chance of failure creates a support burden for us. When
>>> it doesn't work, users are likely to ask for help or report that it
>>> doesn't work in this or that situation.
>>> 4. You're assuming that the majority of custom controls out there are
>>> subclassed Win32 controls. Even when controls have their own window
>>> (see below), in all my years of working in this field, I've seen very
>>> few cases where this kind of reclassing actually works well.
>>> 5. A lot of custom controls which have their own window have the same
>>> class name as other controls. This is becoming more and more common.
>>> Consider useless class names like "DirectUIHWND". In this case, there
>>> is a risk that someone will reclass and be confused as to why a whole
>>> lot of other controls in that app suddenly stop working.
>>> 6. Also more and more common in modern apps is sharing the same
>>> window for multiple controls. In fact, quite a few apps now have a
>>> single window and draw all of their controls into that window. Same
>>> risk as point 5.
>>>
>>> Imagine trying to document all of these possibilities in a way users
>>> can understand. Remember, whenever we include a user exposed feature
>>> into NVDA, it must be thoroughly documented. I can't even begin to
>>> imagine thoroughly documenting this.
>>>
>>> Jamie
>>>
>>> On 2/03/2016 7:59 AM, Grzegorz Zlotowicz wrote:
>>>> Hi and thanks to all for opinions.
>>>> As I mentioned, testing unknown control using console, and then
>>>> making it to respond if it's a WinApi-answering control, is very time consuming.
>>>> So we all agree, that programming maybe even most basic support of
>>>> such controls using raw WinApi, can be helpful.
>>>> Then, let's say we have a unknown control which class is treeview20wndclass.
>>>> Possibility 1:
>>>> write an nvda-addon, which simply inserts earlier defined winapi
>>>> treeview class into the overlay classes of such object.
>>>> It would take few minutes, and is unavailable for non-technical
>>>> users who doesn't know Python at all, and aren't so adventurous to
>>>> do something in the NVDA folder.
>>>> After this time, it can come out, that in fact this treeview doesn't
>>>> support winapi.
>>>> Second variant: on the unknown control user presses nvda+shift+c,
>>>> and dialogbox pops up having title "reclass window treeview20wndclass".
>>>> In this dialog user has simple list of possible raw winapi classes.
>>>> He is not a programmer, and not technically skilled person at all,
>>>> but knows that if the title contains word "treeview20wndclass" and
>>>> one of the item in the list is "treeview", it's definetely worth checking it.
>>>> So it's 3 A.m. in small town somewhere at the end of the world,
>>>> where our non-technical and non-adventurous user lives, trying to
>>>> get some non-mainstream application to work for him.
>>>> He selects treeview, presses OK, and tadaam, it works!
>>>> No add-on writing, no fear of spoiling NVDA, and just 10 seconds of
>>>> activity.
>>>> Of course it's possible, that NVDA will no respond in this window,
>>>> and that the application crashes after receiving tvm_getitem
>>>> message, but it simply will mean, that this particular control is no
>>>> so easy to service, and user from our example would have (in worst
>>>> scenario) to restart the app, and try an other thing.
>>>>
>>>> After all, having a winapi support for common controls programmed,
>>>> doing such simple dialog and dictionary of class mappings to the raw
>>>> winapi classes, seems trivial.
>>>>
>>>> Greetings, Greg.
>>>>
>>>> W dniu 01.03.2016 03:29, James Teh napisał/a:
>>>>> My point was that we don't need a separate GUI for this. As you've
>>>>> just pointed out, you were able to achieve it with little to no
>>>>> NVDA development knowledge.
>>>>>
>>>>> On 1/03/2016 9:06 AM, John Schucker wrote:
>>>>>> Do people really need some technical knowledge? I got a program
>>>>>> working by reclassing a window as terminal, and I basically did
>>>>>> that by grabbing the code for PuTTY and stealing it. That's not
>>>>>> exactly rocket science, and now the thing works where it didn't before.
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> ------------
>>>>>> Site24x7 APM Insight: Get Deep Visibility into Application
>>>>>> Performance APM + Mobile APM + RUM: Monitor 3 App instances at
>>>>>> just $35/Month Monitor end-to-end web transactions and take
>>>>>> corrective actions now Troubleshoot faster and improve end-user experience. Signup Now!
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>>>> _______________________________________________
>>>>>> Nvda-devel mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>>> --------------------------------------------------------------------
>>>> ----------
>>>> Site24x7 APM Insight: Get Deep Visibility into Application
>>>> Performance APM + Mobile APM + RUM: Monitor 3 App instances at just
>>>> $35/Month Monitor end-to-end web transactions and take corrective
>>>> actions now Troubleshoot faster and improve end-user experience. Signup Now!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>> _______________________________________________
>>>> Nvda-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>> ----------------------------------------------------------------------
>> --------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>> _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

Grzegorz Zlotowicz
In reply to this post by James Teh
Hi Jamie and thanks for clarification.
I absolutely agree with all your points.
Also the advantage of add-on is possibility of easy extending and
modyfying it, which in such - an experimental - solution is important.
Ok, i'll move with this addon-related things to thenvda-addons list.

Greetings, Greg.

W dniu 2016-03-02 00:01, James Teh napisał/a:

> Of course, add-ons can do whatever they like; that's the whole point of
> add-ons. However, here are the reasons I don't want to include a user
> exposed UI like this into core:
> 1. Doing anything like this does require at least some very basic
> technical knowledge. Even the whole idea of "class names" is technical.
> If you expose something like this to users, users need to be able to
> understand it.
> 2. If you have something like this, there is an expectation of success.
> There are many different reasons this might not work (see below), but
> explaining those to a user is hard. It's very hard to document something
> for non-technical users when there is a high chance of failure.
> 3. This high chance of failure creates a support burden for us. When it
> doesn't work, users are likely to ask for help or report that it doesn't
> work in this or that situation.
> 4. You're assuming that the majority of custom controls out there are
> subclassed Win32 controls. Even when controls have their own window (see
> below), in all my years of working in this field, I've seen very few
> cases where this kind of reclassing actually works well.
> 5. A lot of custom controls which have their own window have the same
> class name as other controls. This is becoming more and more common.
> Consider useless class names like "DirectUIHWND". In this case, there is
> a risk that someone will reclass and be confused as to why a whole lot
> of other controls in that app suddenly stop working.
> 6. Also more and more common in modern apps is sharing the same window
> for multiple controls. In fact, quite a few apps now have a single
> window and draw all of their controls into that window. Same risk as
> point 5.
>
> Imagine trying to document all of these possibilities in a way users can
> understand. Remember, whenever we include a user exposed feature into
> NVDA, it must be thoroughly documented. I can't even begin to imagine
> thoroughly documenting this.
>
> Jamie
>
> On 2/03/2016 7:59 AM, Grzegorz Zlotowicz wrote:
>> Hi and thanks to all for opinions.
>> As I mentioned, testing unknown control using console, and then making
>> it to respond if it's a WinApi-answering control, is very time consuming.
>> So we all agree, that programming maybe even most basic support of such
>> controls using raw WinApi, can be helpful.
>> Then, let's say we have a unknown control which class is treeview20wndclass.
>> Possibility 1:
>> write an nvda-addon, which simply inserts earlier defined winapi
>> treeview class into the overlay classes of such object.
>> It would take few minutes, and is unavailable for non-technical users
>> who doesn't know Python at all, and aren't so adventurous to do
>> something in the NVDA folder.
>> After this time, it can come out, that in fact this treeview doesn't
>> support winapi.
>> Second variant: on the unknown control user presses nvda+shift+c, and
>> dialogbox pops up having title "reclass window treeview20wndclass".
>> In this dialog user has simple list of possible raw winapi classes.
>> He is not a programmer, and not technically skilled person at all, but
>> knows that if the title contains word "treeview20wndclass" and one of
>> the item in the list is "treeview", it's definetely worth checking it.
>> So it's 3 A.m. in small town somewhere at the end of the world, where
>> our non-technical and non-adventurous user lives, trying to get some
>> non-mainstream application to work for him.
>> He selects treeview, presses OK, and tadaam, it works!
>> No add-on writing, no fear of spoiling NVDA, and just 10 seconds of
>> activity.
>> Of course it's possible, that NVDA will no respond in this window, and
>> that the application crashes after receiving tvm_getitem message, but it
>> simply will mean, that this particular control is no so easy to service,
>> and user from our example would have (in worst scenario) to restart the
>> app, and try an other thing.
>>
>> After all, having a winapi support for common controls programmed, doing
>> such simple dialog and dictionary of class mappings to the raw winapi
>> classes, seems trivial.
>>
>> Greetings, Greg.
>>
>> W dniu 01.03.2016 03:29, James Teh napisał/a:
>>> My point was that we don't need a separate GUI for this. As you've just
>>> pointed out, you were able to achieve it with little to no NVDA
>>> development knowledge.
>>>
>>> On 1/03/2016 9:06 AM, John Schucker wrote:
>>>> Do people really need some technical knowledge? I got a program working
>>>> by reclassing a window as terminal, and I basically did that by grabbing
>>>> the code for PuTTY and stealing it. That's not exactly rocket science,
>>>> and now the thing works where it didn't before.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>> Monitor end-to-end web transactions and take corrective actions now
>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>> _______________________________________________
>>>> Nvda-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>> _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

James Teh
Just wanted to clarify one point: I do still think the NVDAObjects implementing Win32 API should be bundled in core. This way, add-ons can use them. It might even be possible for your UI to build an add-on which contains the relevant magic... but one thing at a time. :)

Sent from a mobile device

> On 3 Mar 2016, at 5:52 AM, Grzegorz Zlotowicz <[hidden email]> wrote:
>
> Hi Jamie and thanks for clarification.
> I absolutely agree with all your points.
> Also the advantage of add-on is possibility of easy extending and
> modyfying it, which in such - an experimental - solution is important.
> Ok, i'll move with this addon-related things to thenvda-addons list.
>
> Greetings, Greg.
>
> W dniu 2016-03-02 00:01, James Teh napisał/a:
>> Of course, add-ons can do whatever they like; that's the whole point of
>> add-ons. However, here are the reasons I don't want to include a user
>> exposed UI like this into core:
>> 1. Doing anything like this does require at least some very basic
>> technical knowledge. Even the whole idea of "class names" is technical.
>> If you expose something like this to users, users need to be able to
>> understand it.
>> 2. If you have something like this, there is an expectation of success.
>> There are many different reasons this might not work (see below), but
>> explaining those to a user is hard. It's very hard to document something
>> for non-technical users when there is a high chance of failure.
>> 3. This high chance of failure creates a support burden for us. When it
>> doesn't work, users are likely to ask for help or report that it doesn't
>> work in this or that situation.
>> 4. You're assuming that the majority of custom controls out there are
>> subclassed Win32 controls. Even when controls have their own window (see
>> below), in all my years of working in this field, I've seen very few
>> cases where this kind of reclassing actually works well.
>> 5. A lot of custom controls which have their own window have the same
>> class name as other controls. This is becoming more and more common.
>> Consider useless class names like "DirectUIHWND". In this case, there is
>> a risk that someone will reclass and be confused as to why a whole lot
>> of other controls in that app suddenly stop working.
>> 6. Also more and more common in modern apps is sharing the same window
>> for multiple controls. In fact, quite a few apps now have a single
>> window and draw all of their controls into that window. Same risk as
>> point 5.
>>
>> Imagine trying to document all of these possibilities in a way users can
>> understand. Remember, whenever we include a user exposed feature into
>> NVDA, it must be thoroughly documented. I can't even begin to imagine
>> thoroughly documenting this.
>>
>> Jamie
>>
>>> On 2/03/2016 7:59 AM, Grzegorz Zlotowicz wrote:
>>> Hi and thanks to all for opinions.
>>> As I mentioned, testing unknown control using console, and then making
>>> it to respond if it's a WinApi-answering control, is very time consuming.
>>> So we all agree, that programming maybe even most basic support of such
>>> controls using raw WinApi, can be helpful.
>>> Then, let's say we have a unknown control which class is treeview20wndclass.
>>> Possibility 1:
>>> write an nvda-addon, which simply inserts earlier defined winapi
>>> treeview class into the overlay classes of such object.
>>> It would take few minutes, and is unavailable for non-technical users
>>> who doesn't know Python at all, and aren't so adventurous to do
>>> something in the NVDA folder.
>>> After this time, it can come out, that in fact this treeview doesn't
>>> support winapi.
>>> Second variant: on the unknown control user presses nvda+shift+c, and
>>> dialogbox pops up having title "reclass window treeview20wndclass".
>>> In this dialog user has simple list of possible raw winapi classes.
>>> He is not a programmer, and not technically skilled person at all, but
>>> knows that if the title contains word "treeview20wndclass" and one of
>>> the item in the list is "treeview", it's definetely worth checking it.
>>> So it's 3 A.m. in small town somewhere at the end of the world, where
>>> our non-technical and non-adventurous user lives, trying to get some
>>> non-mainstream application to work for him.
>>> He selects treeview, presses OK, and tadaam, it works!
>>> No add-on writing, no fear of spoiling NVDA, and just 10 seconds of
>>> activity.
>>> Of course it's possible, that NVDA will no respond in this window, and
>>> that the application crashes after receiving tvm_getitem message, but it
>>> simply will mean, that this particular control is no so easy to service,
>>> and user from our example would have (in worst scenario) to restart the
>>> app, and try an other thing.
>>>
>>> After all, having a winapi support for common controls programmed, doing
>>> such simple dialog and dictionary of class mappings to the raw winapi
>>> classes, seems trivial.
>>>
>>> Greetings, Greg.
>>>
>>> W dniu 01.03.2016 03:29, James Teh napisał/a:
>>>> My point was that we don't need a separate GUI for this. As you've just
>>>> pointed out, you were able to achieve it with little to no NVDA
>>>> development knowledge.
>>>>
>>>>> On 1/03/2016 9:06 AM, John Schucker wrote:
>>>>> Do people really need some technical knowledge? I got a program working
>>>>> by reclassing a window as terminal, and I basically did that by grabbing
>>>>> the code for PuTTY and stealing it. That's not exactly rocket science,
>>>>> and now the thing works where it didn't before.
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>>> Monitor end-to-end web transactions and take corrective actions now
>>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>>> _______________________________________________
>>>>> Nvda-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>> ------------------------------------------------------------------------------
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>> _______________________________________________
>>> Nvda-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

Grzegorz Zlotowicz
I'm not sure, if quality of my code would be worth incorporating into
NVDA core.
If so, it would be nice, and in such case - simply some files would be
moved to the core, and the add-on will be reduced to the gui and users'
class mappings loading and saving.
To make it even easier, I try to subclass the existing modules as deep
as possible, e.g. not only the NVDAObjects.window, but
NVDAObjects.IAccessible.sysTreeView32.TreeViewItem.
Many things in the TreeViewItem are working now, (e.g. getting the count
of elements), so it's no need of copying and pasting working parts to my
code.
Method def _get_treeview_level(self) throws an exception because uses
only IAccessible, so needs to be supplied with the exception handling
Winapi way, or returning 0 in worst case.

Fortunately I have a treeview working now, and have few ideas to make
this task even simpler (simplification of boring virtualAlloc,
readProcessMemory, and VirtualFree sequences), so it looks like an
interesting programmers' adventure, and possibility of better
familiarize myself with Python.
And a small chance that I'll be able to do something in more optimized
way than the NVDA masters, makes thing even more interesting. No, it
wasn't ironic at all, really huge respect for your work: walking through
the NVDA source tree, I'm simply impressed...

Greetings, Greg.

W dniu 2016-03-02 20:56, James Teh napisał/a:

> Just wanted to clarify one point: I do still think the NVDAObjects implementing Win32 API should be bundled in core. This way, add-ons can use them. It might even be possible for your UI to build an add-on which contains the relevant magic... but one thing at a time. :)
>
> Sent from a mobile device
>
>> On 3 Mar 2016, at 5:52 AM, Grzegorz Zlotowicz <[hidden email]> wrote:
>>
>> Hi Jamie and thanks for clarification.
>> I absolutely agree with all your points.
>> Also the advantage of add-on is possibility of easy extending and
>> modyfying it, which in such - an experimental - solution is important.
>> Ok, i'll move with this addon-related things to thenvda-addons list.
>>
>> Greetings, Greg.
>>
>> W dniu 2016-03-02 00:01, James Teh napisał/a:
>>> Of course, add-ons can do whatever they like; that's the whole point of
>>> add-ons. However, here are the reasons I don't want to include a user
>>> exposed UI like this into core:
>>> 1. Doing anything like this does require at least some very basic
>>> technical knowledge. Even the whole idea of "class names" is technical.
>>> If you expose something like this to users, users need to be able to
>>> understand it.
>>> 2. If you have something like this, there is an expectation of success.
>>> There are many different reasons this might not work (see below), but
>>> explaining those to a user is hard. It's very hard to document something
>>> for non-technical users when there is a high chance of failure.
>>> 3. This high chance of failure creates a support burden for us. When it
>>> doesn't work, users are likely to ask for help or report that it doesn't
>>> work in this or that situation.
>>> 4. You're assuming that the majority of custom controls out there are
>>> subclassed Win32 controls. Even when controls have their own window (see
>>> below), in all my years of working in this field, I've seen very few
>>> cases where this kind of reclassing actually works well.
>>> 5. A lot of custom controls which have their own window have the same
>>> class name as other controls. This is becoming more and more common.
>>> Consider useless class names like "DirectUIHWND". In this case, there is
>>> a risk that someone will reclass and be confused as to why a whole lot
>>> of other controls in that app suddenly stop working.
>>> 6. Also more and more common in modern apps is sharing the same window
>>> for multiple controls. In fact, quite a few apps now have a single
>>> window and draw all of their controls into that window. Same risk as
>>> point 5.
>>>
>>> Imagine trying to document all of these possibilities in a way users can
>>> understand. Remember, whenever we include a user exposed feature into
>>> NVDA, it must be thoroughly documented. I can't even begin to imagine
>>> thoroughly documenting this.
>>>
>>> Jamie
>>>
>>>> On 2/03/2016 7:59 AM, Grzegorz Zlotowicz wrote:
>>>> Hi and thanks to all for opinions.
>>>> As I mentioned, testing unknown control using console, and then making
>>>> it to respond if it's a WinApi-answering control, is very time consuming.
>>>> So we all agree, that programming maybe even most basic support of such
>>>> controls using raw WinApi, can be helpful.
>>>> Then, let's say we have a unknown control which class is treeview20wndclass.
>>>> Possibility 1:
>>>> write an nvda-addon, which simply inserts earlier defined winapi
>>>> treeview class into the overlay classes of such object.
>>>> It would take few minutes, and is unavailable for non-technical users
>>>> who doesn't know Python at all, and aren't so adventurous to do
>>>> something in the NVDA folder.
>>>> After this time, it can come out, that in fact this treeview doesn't
>>>> support winapi.
>>>> Second variant: on the unknown control user presses nvda+shift+c, and
>>>> dialogbox pops up having title "reclass window treeview20wndclass".
>>>> In this dialog user has simple list of possible raw winapi classes.
>>>> He is not a programmer, and not technically skilled person at all, but
>>>> knows that if the title contains word "treeview20wndclass" and one of
>>>> the item in the list is "treeview", it's definetely worth checking it.
>>>> So it's 3 A.m. in small town somewhere at the end of the world, where
>>>> our non-technical and non-adventurous user lives, trying to get some
>>>> non-mainstream application to work for him.
>>>> He selects treeview, presses OK, and tadaam, it works!
>>>> No add-on writing, no fear of spoiling NVDA, and just 10 seconds of
>>>> activity.
>>>> Of course it's possible, that NVDA will no respond in this window, and
>>>> that the application crashes after receiving tvm_getitem message, but it
>>>> simply will mean, that this particular control is no so easy to service,
>>>> and user from our example would have (in worst scenario) to restart the
>>>> app, and try an other thing.
>>>>
>>>> After all, having a winapi support for common controls programmed, doing
>>>> such simple dialog and dictionary of class mappings to the raw winapi
>>>> classes, seems trivial.
>>>>
>>>> Greetings, Greg.
>>>>
>>>> W dniu 01.03.2016 03:29, James Teh napisał/a:
>>>>> My point was that we don't need a separate GUI for this. As you've just
>>>>> pointed out, you were able to achieve it with little to no NVDA
>>>>> development knowledge.
>>>>>
>>>>>> On 1/03/2016 9:06 AM, John Schucker wrote:
>>>>>> Do people really need some technical knowledge? I got a program working
>>>>>> by reclassing a window as terminal, and I basically did that by grabbing
>>>>>> the code for PuTTY and stealing it. That's not exactly rocket science,
>>>>>> and now the thing works where it didn't before.
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>>>> Monitor end-to-end web transactions and take corrective actions now
>>>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>>>> _______________________________________________
>>>>>> Nvda-devel mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>>> ------------------------------------------------------------------------------
>>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>> Monitor end-to-end web transactions and take corrective actions now
>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>> _______________________________________________
>>>> Nvda-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>> _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Window manual re-classing

James Teh
Be aware that the ReadProcessMemory, etc. code is going to need to be replaced with our own cross-process implementation, since it doesn't work with 64 bit properly. That said, if you can propose an API which simplifies this for the caller (not its implementation, just the design), I'd love to hear it. I've tried to come up with something, but I always run into snags because callers often need to do stuff with the memory directly (e.g. calling another C function on it), so you still have to manually deal with ctypes pointers.

Jamie

On 3/03/2016 6:49 AM, Grzegorz Zlotowicz wrote:
I'm not sure, if quality of my code would be worth incorporating into 
NVDA core.
If so, it would be nice, and in such case - simply some files would be 
moved to the core, and the add-on will be reduced to the gui and users' 
class mappings loading and saving.
To make it even easier, I try to subclass the existing modules as deep 
as possible, e.g. not only the NVDAObjects.window, but 
NVDAObjects.IAccessible.sysTreeView32.TreeViewItem.
Many things in the TreeViewItem are working now, (e.g. getting the count 
of elements), so it's no need of copying and pasting working parts to my 
code.
Method def _get_treeview_level(self) throws an exception because uses 
only IAccessible, so needs to be supplied with the exception handling 
Winapi way, or returning 0 in worst case.

Fortunately I have a treeview working now, and have few ideas to make 
this task even simpler (simplification of boring virtualAlloc, 
readProcessMemory, and VirtualFree sequences), so it looks like an 
interesting programmers' adventure, and possibility of better 
familiarize myself with Python.
And a small chance that I'll be able to do something in more optimized 
way than the NVDA masters, makes thing even more interesting. No, it 
wasn't ironic at all, really huge respect for your work: walking through 
the NVDA source tree, I'm simply impressed...

Greetings, Greg.

W dniu 2016-03-02 20:56, James Teh napisał/a:
Just wanted to clarify one point: I do still think the NVDAObjects implementing Win32 API should be bundled in core. This way, add-ons can use them. It might even be possible for your UI to build an add-on which contains the relevant magic... but one thing at a time. :)

Sent from a mobile device

On 3 Mar 2016, at 5:52 AM, Grzegorz Zlotowicz [hidden email] wrote:

Hi Jamie and thanks for clarification.
I absolutely agree with all your points.
Also the advantage of add-on is possibility of easy extending and
modyfying it, which in such - an experimental - solution is important.
Ok, i'll move with this addon-related things to thenvda-addons list.

Greetings, Greg.

W dniu 2016-03-02 00:01, James Teh napisał/a:
Of course, add-ons can do whatever they like; that's the whole point of
add-ons. However, here are the reasons I don't want to include a user
exposed UI like this into core:
1. Doing anything like this does require at least some very basic
technical knowledge. Even the whole idea of "class names" is technical.
If you expose something like this to users, users need to be able to
understand it.
2. If you have something like this, there is an expectation of success.
There are many different reasons this might not work (see below), but
explaining those to a user is hard. It's very hard to document something
for non-technical users when there is a high chance of failure.
3. This high chance of failure creates a support burden for us. When it
doesn't work, users are likely to ask for help or report that it doesn't
work in this or that situation.
4. You're assuming that the majority of custom controls out there are
subclassed Win32 controls. Even when controls have their own window (see
below), in all my years of working in this field, I've seen very few
cases where this kind of reclassing actually works well.
5. A lot of custom controls which have their own window have the same
class name as other controls. This is becoming more and more common.
Consider useless class names like "DirectUIHWND". In this case, there is
a risk that someone will reclass and be confused as to why a whole lot
of other controls in that app suddenly stop working.
6. Also more and more common in modern apps is sharing the same window
for multiple controls. In fact, quite a few apps now have a single
window and draw all of their controls into that window. Same risk as
point 5.

Imagine trying to document all of these possibilities in a way users can
understand. Remember, whenever we include a user exposed feature into
NVDA, it must be thoroughly documented. I can't even begin to imagine
thoroughly documenting this.

Jamie

On 2/03/2016 7:59 AM, Grzegorz Zlotowicz wrote:
Hi and thanks to all for opinions.
As I mentioned, testing unknown control using console, and then making
it to respond if it's a WinApi-answering control, is very time consuming.
So we all agree, that programming maybe even most basic support of such
controls using raw WinApi, can be helpful.
Then, let's say we have a unknown control which class is treeview20wndclass.
Possibility 1:
write an nvda-addon, which simply inserts earlier defined winapi
treeview class into the overlay classes of such object.
It would take few minutes, and is unavailable for non-technical users
who doesn't know Python at all, and aren't so adventurous to do
something in the NVDA folder.
After this time, it can come out, that in fact this treeview doesn't
support winapi.
Second variant: on the unknown control user presses nvda+shift+c, and
dialogbox pops up having title "reclass window treeview20wndclass".
In this dialog user has simple list of possible raw winapi classes.
He is not a programmer, and not technically skilled person at all, but
knows that if the title contains word "treeview20wndclass" and one of
the item in the list is "treeview", it's definetely worth checking it.
So it's 3 A.m. in small town somewhere at the end of the world, where
our non-technical and non-adventurous user lives, trying to get some
non-mainstream application to work for him.
He selects treeview, presses OK, and tadaam, it works!
No add-on writing, no fear of spoiling NVDA, and just 10 seconds of
activity.
Of course it's possible, that NVDA will no respond in this window, and
that the application crashes after receiving tvm_getitem message, but it
simply will mean, that this particular control is no so easy to service,
and user from our example would have (in worst scenario) to restart the
app, and try an other thing.

After all, having a winapi support for common controls programmed, doing
such simple dialog and dictionary of class mappings to the raw winapi
classes, seems trivial.

Greetings, Greg.

W dniu 01.03.2016 03:29, James Teh napisał/a:
My point was that we don't need a separate GUI for this. As you've just
pointed out, you were able to achieve it with little to no NVDA
development knowledge.

On 1/03/2016 9:06 AM, John Schucker wrote:
Do people really need some technical knowledge? I got a program working
by reclassing a window as terminal, and I basically did that by grabbing
the code for PuTTY and stealing it. That's not exactly rocket science,
and now the thing works where it didn't before.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

-- 
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
12