Moving the Mouse and Focus in WPF

[MikeHughes]

Sorry I have not had much time to assist but I have been playing this morning and have come up with this

It relies on a dll called TestApiCore.dll from a codex site.

I have uploaded a ws and a dll - both need to be put in the same directory
Then you should be able to run

#.Demo.ButtonMouse
#.Demo.ClickTab
#.Demo.ClickTabMouse
#.Demo.SimInput

Assumes ⎕ml 3 ⎕io 1

Main functions are in #.WPF
(row col)←MouseCurrent returns current mouse position as row column

{la} MouseMoveTo ra
If monadic mouse moves directly to ra
otherwise la is starting point and time taken to reach it
(row col [secs]) ⍝ if either row col are ⍬ and then current row or col is used, if secs omitted 3 is assumed
ra is
row col ⍝ in absolute pixels
or object
or object row col ⍝(within object)
or object 'TopRight' ⍝ where Top Left Right Middle Bottom Centre Center are valid

MouseClick 'Left'
MouseClick 'Right'

Underlying dll does more such as drag etc.

[MikeHughes]

Sorry I should have given the page for the dll information

http://testapi.codeplex.com/

[Dick Bowman]

Thankyou, it just needed a final mutation...

(gt.Transform pt).(X Y)

to get some numbers I could use in APL (and then allow for the negative values).

I'm thoroughly exasperated with .NET - one of the things that drew me to APL in the first place was that I could build my knowledge in a logical way (some sort of skill transference), but with .NET it so often seems that the answer can't be deduced from prior knowledge of anything except the answer. Feels like it was put together by putting a whole heap of computer programmers into an exam room, setting each of them a different question and strictly enforcing a "no collaborating" rule.

I am seriously concerned about what this means for the casual APL programmer wanting to make themselves quick user interfaces. Do we say "you can manipulate your data very easily - but when you want to display some results you are in the same boat as the C++ programmer except that you can't understand the documentation even after you've found it".

It's cold, ranting keeps me warm.

[MikeHughes]

I agree .Net is huge and unhelpful at times and the documentation sucks but then that has always been true of external interfaces to APL. However the power and ability it gives us on a Windows platform is enormous and in my opinion worth the struggle, others will disagree.

But we all have a choice - stay with []wc and produce GUI interfaces that start looking dated or bite the bullet and try and compete. The casual APL user doesn't need to worry about dated GUIs and can continue with []wc if they wish. If they want quick displays and only quick displays then they can get that. Those of us who want to sell our products to companies and individuals who are used to other windows products on their desktops don't have a choice but to beat .Net into submission. Once utilities are in place then these will also become quick and easy to use as well - see my mouse examples earlier.

I remember struggling with all the auxillary processors - AP126, AP123 and APwhatever when I started with APL until nice utilities were written on top of them. Even maintaining the communication with some of them was obtuse, let alone the command strings you had to send them to get something useful back. The error codes meant very little even when you looked them up. So the problems with .Net are not new.

The challenge is - we are at the pre utility stage - when we have the utilities in place it will seem a much friendlier place to be.

Dyalog have given us a great bridge to the Windows .Net arena and this external world is complex (it will continue to be so whatever we say or do) and I doubt Dyalog will ever be able to make it simple (and up to date) with []WC,et al without taking on many experts in the .Net field which unless we are willing to pay more for our licenses they probably can't afford. The .Net bridge to the outside world is more flexible than the old Auxillary Processors, which on one hand makes it more difficult but on the other hand opens up many more possibilities. It just needs taming in an APL sense.

We have to try and build some utilities, because after all, thats all []wc, []ws and []wg are - they are system cover functions to a subset of the same strange external calls to the last generation of Windows - now we have to write cover functions for ourselves or wait for someone else to do it and possibly pay them for their hard work, as I dont think Dyalog is in a position to provide them for us quickly.

You are right - rants keep out the cold :-)