Hi Greg,
Your apology for this message is seen and accepted, but I thought I'd
reply to a few points with more reasoning, which will probably only
confirm what you've now realized. And, by the way, I've provided a
solution.
On approximately 9/17/2004 12:35 AM, came the following characters from
the keyboard of Greg Osborne:
I'm sure I really shouldn't be responding to this. It seems an open
invitation to start trouble, and that's not truly my intent. I have to
wonder why Glen wanted to be so knit-picky on my bug report. Obviously,
there isn't a 6.xx version out there, and won't be for a long time, so how
many 0's preceed the version shouldn't matter. Of course, I was
impricise, and I'm sure that's where he was coming from, but I knew what
version I had, just not where the .'s and 0's were placed, and didn't feel
such a minor detail mattered, but excuse me for thinking on that.
The point here is just that if the precise version isn't known, then
guessing at what version it might be, and trying something, may be
wasting lots of time. Time is precious.
Glen, I don't know if you're a developer,
I've been a software developer for 25 years, now. I've done a little
minor development on Win32::GUI, but I am neither an expert in the
Windows API nor in Perl's XS interfaces. So doing work on Win32::GUI is
not particularly easy for me, although I'm understanding more of the
internals as time goes on, but it is a useful package, and I have some
strong reasons to use it for some large projects (on which is where I
really want to spend my development time). When I run into bugs in
Win32::GUI, I tear out my hair, report them here, hope someone else is
knowledgable enough and interested enough to fix it in the timeframe I
need the fix in... and if not, I try to fix it myself, and the timeframe
gets blown to pieces because I don't have the expertise to really
understand some of what is going on.
Let me tell you about one bug fix estimation rule of thumb I learned
from a co-worker in the early days, and have had proved to me over and
over, more times that I'd like. If you can repeatably reproduce the
problem in a minute, you can fix it in a day. If you can repeatably
reproduce the problem in a day, you can fix it in a week. If you can
repeatably reproduce the problem in a week, you can fix it in a year.
If you can't repeatably reproduce the problem, it is unlikely to ever
get fixed.
So the provision of a test case that repeatably reproduces the problem
is a great boon to analyzing the problem. It cannot be overstated how
great a boon it is.
and thus were personally anoyed
with my report or not, or if you felt my email was a classic instance of
"what not to do" so felt obligated to use me to make an example. In
either case, I didn't appreciate it. Neither the version, nor my
description were so bad that I felt I was wasting anyone's time,
If the problem was a known problem, the report was probably good enough.
Since the problem wasn't a known problem (note: I couldn't see that
you had any responses in nearly two weeks, so since I hadn't heard of
the problem either, I conclude it is not a known problem), then it is
simply prudent to make sure that the original reporter can actually
reproduce the problem in a test case, before examining it further. And
providing that test case is simply time efficiency. Remember, in Open
Source, most of the people are volunteers, and time is precious.
and I had
looked for previous versions not long before I posted that, and was
supposed to have had an email telling me when the next updates were out
(which I haven't recieved, so thanks on that end).
(You are welcome on that end.)
If you want code, here you go:
I'll give the code a whirl, to see if I can reproduce it on one of the
versions of Win32::GUI that I have installed. And indeed, it reproduces
on the latest development branch of Win32::GUI.
use Win32::GUI;
my( $Window, $Bitmap );
$Window = new Win32::GUI::Window(
-name => "Window",
-top => 0,
-left => 0,
-height => 300,
-width => 300
);
$Bitmap = new Win32::GUI::Bitmap( 'image.bmp' );
$Window->AddButton(
-name => "Button",
-top => 0,
-left => 0,
-height => 300,
-width => 300,
-bitmap => $Bitmap
);
$Window->Show();
Win32::GUI::Dialog();
sub Window_Terminate {
return -1;
}
That's the code which works.
Here's the code which doesn't.
I think, it will quickly become apparent, there was no need for all this
:p
use Win32::GUI;
my( $Window, $Bitmap );
$Window = new Win32::GUI::Window(
-name => "Window",
-top => 0,
-left => 0,
-height => 300,
-width => 300
);
$Bitmap = new Win32::GUI::Bitmap( 'image.bmp' );
$Window->AddButton(
-name => "Button",
-top => 0,
-left => 0,
-height => 300,
-width => 300
, -bitmap => 1, # add this line here, and it works
);
$Window->Button->SetImage( $Bitmap );
$Window->Show();
Win32::GUI::Dialog();
sub Window_Terminate {
return -1;
}
Now, you ask why waste my time with this? No one wants to set an image
after creation of a button anyways, right?
That was a simple example, sense examples seemed to be required, to point
out what doesn't work :p
Absolutely. The smaller and simpler the better.
The intent of my code, which I worked with for weeks, mostly not having
images show up before I figured out what actually worked and what didn't,
was setting up a series of buttons which needed to change their images in
certain instances. I wanted to be able to use SetImage to get the buttons
to change, rather than have to destroy the button, create a new button
with the new image, etc.
And that is absolutely a good idea. Destroying and creating buttons
probably exercises memory leaks in Win32::GUI. There are seemingly
quite a few things that never get "returned" the way Win32::GUI is
coded. But it is still useful for many applications in spite of that.
Especially applications that don't destroy and recreate things a lot :)
Perhaps I am blowing this _way out of proportion, but I think my
description matched the code above, and was far more concise.
It was more concise, yes. It didn't get you a solution, either, because
it didn't ring the right bell in my brain (or, apparently, anyone else's
either). And it was not clear from your description that you had
omitted the -bitmap, as well as the "initial bitmap file" sort of
parameter. And the code made it obvious... if you want to use bitmaps,
you must supply the -bitmap option. The -bitmap option doesn't require
an actual bitmap as an initial parameter, as you assumed, but it must be
present. What more should be said? Communications is the hardest part
of computer programming... and I don't mean TCP/IP.
I won't waste your time again with reports,ough. If you're that
knit-picky, perhaps you need to find them yourself.
This (and other references to knit-picky [and hey, if you want
nit-picky, I'll note that you spelled nit-picky incorrectly]) was the
offensive part, that you apologized for. Water under the bridge now.
Hope the solution helps you.
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
