Re: Problem using PictureBox_Resize event instead of subclassing

microsoft.public.vb.general.discussion

2 Jul 2009 9:18 AM

Alfie [UK]

On Wed, 01 Jul 2009 21:28:01 +0100, MM <kylix***@yahoo.co.uk> wrote:

>First off, it was Olaf's (Schmidt's) suggestion to "steal" a hidden
>picturebox for its Resize event instead of subclassing, and it works!

Yup, it's an interesting way to avoid WndProc subclassing :)

What I was getting at it is that in Olaf's demo the MMTimer is only
being used as an asynchronous trigger (i.e. it only raises a dummy
event to let your app run code at specific timesteps), all of the
logic about playing notes/displaying to screen is enacted in the
'CheckForNextNote/PlayNote' functions.

>
>However, in the meantime I have discovered SmartSubclass
>http://www.visual-basic.com.ar/vbsmart/library/smartsubclass/smartsubclass.htm
>and this gives me everything I need.

If you go the full subclassing route then you do away with the dummy
picturebox/event and send a custom message to your app instead. You
can then send your own wParam/lParam as part of that message, if
needed, as you have full control over how those parameters are used.

>
>In the actual tick event (callback) from timeSetEvent I am allowed (as
>per MS docs) to call midiOutShortMsg, but in order to see the virtual
>key moving up or down on the screen "piano" I need to send on the data
>used in the midiOutShortMsg call.

As above, you'd handle that in your 'PlayNote' function, something
like;

Clear current 'keypresses'
Send new midi msg
Show new 'keypresses'

If you have different 'sustains' on 'keypresses' then you would need
some logic to check which 'keypresses' to clear/show on each MMTimer
tick which may need to occur in CheckForNextNote.

--
Alfie [UK]
<http://www.delphia.co.uk/>
STOP THE HATRED: End lactose intolerance!

2 Jul 2009 2:45 PM

Schmidt

"Alfie [UK]" <alfie@mail.invalid> schrieb im Newsbeitrag
news:tiso45p96a2jshsvl4hiaghrhhrn8vntro@4ax.com...

Hi Alfie and MM -

I'm not seeing any of MMs postings in my NewsReader -
maybe the MS-Server has some syncing problems currently,
so I reply here to that post of Alfie...

> What I was getting at it is that in Olaf's demo the MMTimer is only
> being used as an asynchronous trigger (i.e. it only raises a dummy
> event to let your app run code at specific timesteps), all of the
> logic about playing notes/displaying to screen is enacted in the
> 'CheckForNextNote/PlayNote' functions.

Yep - normally one should not need any additional params
within the MMTimer-Callback (and its internal PostMessage-
Call), since the whole example is working like a state-machine,
which simply gets "reminded" with an interval of about 2msec
to check "everything" related to the currently played stream -
able to choose the next actions - or just skip any actions,
if there's "not yet the right time for it".

> >However, in the meantime I have discovered SmartSubclass
>
>http://www.visual-basic.com.ar/vbsmart/library/smartsubclass/smartsubclass.
htm
> >and this gives me everything I need.

MM - yep, that would be also a possible solution, but it
introduces "full blown subclassing" into your solution, which
could be avoided IMO for the sake of a more stable IDE-
debugging-behaviour.

Show quoteHide quote

> >In the actual tick event (callback) from timeSetEvent I am
> >allowed (as per MS docs) to call midiOutShortMsg,
> >but in order to see the virtualkey moving up or down on the
> >screen "piano" I need to send on the data used in the
> >midiOutShortMsg call.
>
> As above, you'd handle that in your 'PlayNote' function,
> something like;
>
> Clear current 'keypresses'
> Send new midi msg
> Show new 'keypresses'
>
> If you have different 'sustains' on 'keypresses' then you would
> need some logic to check which 'keypresses' to clear/show
> on each MMTimer tick which may need to occur in
> CheckForNextNote.

Yep - that was the intention of the small Demo - it can be
enhanced of course from the simple "play next note-scheme"
to someting that supports more "current states" or more
"do next"-actions - all that within a granularity of 2msec -
MM will just need to store such additional actions within
the incoming Control-Events on his Form (e.g. whilst a
stream is playing its notes, just store a keyboard-action,
caused by user-interaction inside the appropriate Ctl-
Event within an additional "Next-User-Action"-structure -
and exit the KeyboardCtl-Event immediately - as long
as the Stream retriggers itself, the just stored "Next-userAction"
is then handled 1-2msec later in the normal "process everything
that needs to be played now" Routine.
That routine in my smaller example is the CheckForNextNote-
routine - it can of course be renamed to:
CheckForNextNote_AlsoCheckForNextUserActions
and just exit that routine with only the next retriggering, if
the used structures (and time-deltas) don't suggest, that
a Note should be played - or if there's no current User-
Action stored in the "NextUserAction-structure" currently
(or Collection whatever) ... but if there is a next-note,
matching the time-delta - or there is a next user-action
to be played "now" in addition - or if there is a pending
GUI-refresh/update, just react appropriately - and after
each of the current actions (Notes-playing, User-Actions,
GUI-refreshs) was done, just retrigger for the next
round (with that 1-2msec timeout) where everything is
done in the same way - maybe you got additional User-
Events from your GUI in that interval - maybe your
"playing Notes" trigger some other Events regarding GUI-
Refreshs - no problem - just store all these new additional
Actions within appropriate temporary container-structures
and exit these Events. Everything you've stored temporarily
will be played only 1-2msec later in your routine:
CheckForNextNote_AlsoCheckForNextUserActions

I could post more concrete code (based on my former
example), if MM could clearly describe the additional
requirements he would expect on top of that simplified
"Play-Next-Note-Scheme".

Olaf