Looks like a winner! :alright: WinXP
Posted on 2002-04-23 19:11:34 by bitRAKE
Great!

I will assume it works on NT and 2000 as well.

Lastly, one thing that needed fixing that no one else noticed is that the second button is supose to have a 60x60 picture on it.

But fodder's graphic doesnt show it. So i think i know why this is. The microsoft code to build your own masks using a wierd API that has limitations to about 30 pixels. It says after this it fails. And i think this is why you see only one of the two start up pictures. The house is 23x23. And the other is 60x60.

So after some softicing, i realize the api did nothing anyways (what went in came out) in terms of pixel size, so i modified the 'DrawTransparentBitmap' funciton, and removed this api. Both graphics appear as normal on 98 still (as anticipated).

Would everyone try this one: 95, 98, 2000, NT, ME, XP

You should see two graphics off the start, and the third box's graphic will only appear when you click the menu item for it.

Thanx again for helping me on this everyone!!!
:alright:
NaN
Posted on 2002-04-23 19:32:49 by NaN
No luck on this one NaN, or picture on button 2.
Posted on 2002-04-23 19:39:52 by bitRAKE
What do you mean OR something else go wrong? ie) no pictures?

NaN
Posted on 2002-04-23 19:46:50 by NaN
Sorry, play with words isn't good with bug report. :)
Just no picture on button 2.
Posted on 2002-04-23 19:58:05 by bitRAKE
Kool.. Well after re-reading the MSDN on this, i realize i made an error in my thoughts. The DPtoLP API says it cant be greater than 27 BITS, however i read it as 27 pixels, which are apples and oranges. So this api can easily suport a bitmap 60x60.

So im still left clueless where the NT box's fail to display the second graphic. :rolleyes: (Im really starting to NOT like NT ).

Any thougthts? I trust the first 23x23 is being displayed. If you enable menu 3, and select add graphic from it, can you see the other 23x23 graphic??

Thanx.
:alright:
NaN
Posted on 2002-04-23 20:04:49 by NaN
Yes, just that one gfx missing: :stupid:
Posted on 2002-04-23 20:06:04 by bitRAKE
This is what 9x sees...
Posted on 2002-04-23 20:07:28 by NaN
The button is too small. I can see it just by making the button bigger. :)

mov hBut2, $invoke( MButton, addr sz002, hWin, 130,0,80,76, hBMenu2, 2200 )
Posted on 2002-04-23 20:11:58 by bitRAKE
Awesome bitRAKE

Good job! I didnt realize that NT needed to be so specific. I will tabulate what the size of the control needs to be per bitmap used and add this info into the README.TXT


Well, thanx to your help, i think i have all problems pounded out!

Thanx again..
:alright:
NaN
Posted on 2002-04-23 20:31:32 by NaN
NaN, if the CREATESTRUCT.lpName was merely the pointer
supplied on the CreateWindow call, it wouldn't be safe
to use this in your control - who knows in which way this
was supplied? It could be data with temporary life cycle
(created in a temporary heap buffer, or a local buffer).

Iirc, NT does a lot of parameter copying back and forth
(in a "don't trust the user, he WILL try to crash our
kernel" way), so your "temporary OS buffer" theory might
not be too farfetched.

It also makes a lot of sense storing the window caption
yourself, you wont need to WM_GETTEXT when you need to
repaint, and you only depend on your own code... you know
what you get.

Your tryme works fine on win2k now, well at least the text
does ;). trymeagain doesn't show button2 picture.


(Im really starting to NOT like NT ).

You ought to like it... NT enforces the PlatformSDK while
9x lets you get away with a lot of bad programming... some
of which will eventually lead to severe leaks, crashes etc.

Remember, always assume that YOU are doing something wrong ;).
Great work, now you just need to change the buttondraw status
to nonclicked when the mouse is away from the button, and there's
a useful control :).
Posted on 2002-04-23 20:45:38 by f0dder
I see you've edited you post, as you have yourself discovered the same.

For NT boxes in particular, but is good practice over all. The size of the control width and height must adhear to this:
Width >= BitMapSize + 12
Height >= BitMpaSize + 16


And remember that this is designed for SQUARE bitmaps.
Posted on 2002-04-23 20:59:29 by NaN

I see you've edited you post, as you have yourself discovered the same.

Huh? Realized what? And edited what post? :confused:
Posted on 2002-04-23 21:05:50 by f0dder
Originally posted by f0dder
NaN, if the CREATESTRUCT.lpName was merely the pointer
supplied on the CreateWindow call, it wouldn't be safe
to use this in your control - who knows in which way this
was supplied? It could be data with temporary life cycle
(created in a temporary heap buffer, or a local buffer).


I see your point, but i TRUSTED the MSDN! It said it was a pointer, and when created i passed a pointer. It would be nice for it to say that this is an INTERNAL pointer to copied text. Then i wouldnt have thougth twice using a buffer. Im really trying to keep the control as unbloated as possible, so saving a pointer is much better than an array of bytes.

You ought to like it... NT enforces the PlatformSDK while
9x lets you get away with a lot of bad programming... some
of which will eventually lead to severe leaks, crashes etc.


Im sorry, but i dont see the SDK being enforced (as it is documented). Again, i saw with softice that the pointer is transparent directly to the address of my text data (on win 9x) and confirms the information on the MSDN. In reality, windows NT goes a step further and doesnt tell you.

I always use the web MSDN because it has OS version information, but this time it let me down. This is what took me all day to debug :rolleyes: . However, your right, im now a better programmer, cause the experience has taught me alot about the 'dont trust the programmer' menality of NT :)

Great work, now you just need to change the buttondraw status to nonclicked when the mouse is away from the button, and there's a useful control :).


I thought I fixed this already. :confused:

PS: fodder, we're leap-froggin posts. You replied to me, as i replied to bitrake, which you then replied in confusion, and i replied to your first with this, only to edit this comment after I realize your confuse. So i ask, whos on first? (LoL)

Thanx again!
:alright:
Posted on 2002-04-23 21:12:56 by NaN
Well... the PlatformSDK certainly isn't clear on
where the data the pointer points to is stored.
In such cases, take no chances :). If you got a
pointer to some structure in response to a window
message, you shouldn't store that pointer... you
should copy whatever info you need from it. Same
thing as with HDCs, really... unless you specify
a CS_OWNDC, you need to constantly get/reget the hdc.

I think the reason I see the "you shouldn't just store
the pointer" as a very logical thing, and don't really
feel there's any problem with the PSDK info (though
as a big company, m$ ought to remove a few ambiguities
etc) is that I know how *I* often write code... pass
something to a function, use it there temporarily,
destroy later, et cetera. I also use a lot of "black box"
programming, which means that "objects" should store
their "own properties" - in the case of a control,
things like the caption.

I don't think (but don't know if) there's any "default
storage" for a thing like the window caption. After all,
not all windows need captions, so why should *all* windows
waste space for a caption buffer? Or even a pointer to a
caption buffer... at least that's the way I think.

Sometimes the wording in the PSDK can be a bit confusing,
and often special cases aren't covered. Too bad when those
special cases can have weird side effects. I still think
it's a very good set of documentation, the best OS/API
reference I've ever seen (*u*x manpages, booyah). But sure,
there are a few (very few imo) situations where on can
be seriously in doubt who's erring - you or the API.


I thought I fixed this already

You fixed the "event is not generated if mouse is outside
rect when button is released", but you haven't yet duplicated
the "redraw button in raised state when mouse is outside rect".
This is purely cosmetic, but it is windows default behaviour
and I've grown so used to it that buttons not following this
standard scare me ;P

*pat on the back*, good work NaN.
Posted on 2002-04-23 21:43:41 by f0dder
Thanks!

Umm I now know what your were getting at with the click event.

Originally, i tried to support mouse over events (like IE) where the icon would become colored when the mouse is over it. The problem was i could use WM_NCHITTEST to realize the mouse is over the control. However, i had no way of realizeing the mouse was NOT over the control.

I dont know how this is done. The only way i can concieve of is a HUGE work around and 98% guarenteed not to be the correct way, so i didnt do it. (basically register a bigger window around the control, but have no drawing properties ~ Very bad idea, but the best i could think of).

If you know how to track the mouse outside the control (with out click events) im intereseted!! Last i read MouseCapture events are based on click events, so im running out of messages to process?? :(

Thanx again!
:alright:
NaN
Posted on 2002-04-23 21:57:57 by NaN
An idea for the "hot stuff" (mouseover)... Well, I think you should/could
do it with SetCapture. Once mouse enters your control, highlight it, and
SetCapture. When the mouse leaves your control, draw normal, and ReleaseCapture.
However, PSDK says that only the foreground window can capture the mouse :/,
so I dunno if this way is feasible. There are some messages for mouse tracking
(WM_MOUSEHOVER, WM_MOUSELEAVE, ...) but those are NT4+ and 98+. But hey,
screw those 95 users, they probably wont care about hottracking anyway.

Using the capture idea for hottracking (probably wont work...) would also
require a bit more logic to handle the case when you're actually clicking
the button and moving the mouse outside the control... you wouldn't want
to ReleaseCapture if the button is currently being clicked :).
Posted on 2002-04-23 22:11:01 by f0dder
I will look into it... dunno what will turn up tho :-/

Another idea i had was to start a timer when WM_NCHITTEST starts (at its best resolution), and then "Time out" indicating the mouse is left the control, and stop the timer.

This *i think* is a sloppy work around, because the os would be sending a good multitide of timer messages to your control.

NaN
Posted on 2002-04-23 22:19:51 by NaN
If the SetCapture method of hottracking doesn't work (which PSDK
would indicate it doesn't), I can't think of an all-os way to handle it.
But really, it's a cosmetic issue, so using the 98+ hottracking messages
isn't a problem. Big deal if there's no hottracking on obsolete old
95, it's not like applications wont work without it :).

I'd put "draw unpressed when mouse is out" higher on the todo-list
than hottracking though :).
Posted on 2002-04-23 22:25:40 by f0dder