I have an image button in which I change the image frequently using the CONTROL SET IMGBUTTON function. Normally it works fine. However, occasionally when I have another thread running which does extensive GDI functions, my image on my image button will not display. Utilities show no GDI resource leaks. Can GDI functions in different threads "collide" some how?
-
Brent Boshart -
There is important restriction: any bitmap can be selected for one device context at a time.
------------------
-
Another possible trap is with device contexts themselves. A DC from the GDI pool can only be in use by one 'section' of code at a time. TTBOMK, this comment refers to "common device contexts" only.
For example, if a DC to a window is obtained during %WM_PAINT by calling BeginPaint(), then it is quite likely that a call to GetDC() to obtain the same DC (or the DC of a child control that is formed from the parent DC) will likely fail. This behavior varies between versions of Windows too.
In fact, one of the early PB/DLL example files had this problem, but it did not become known until the release of Windows 98. In particular, the demo code called a sub that drew a gradient in the client area of the window. However, instead of passing the DC from the %WM_PAINT handler to the sub, the code passed the handle to the window instead. As a result, the subsequent GetDC() call in the sub failed, and resulted in the app producing strange repainting effects on some systems.
Windows programming can be quite... ahem... interesting... when these types of problems show up...!
------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>Lance
mailto:[email protected]Comment
-
Based on a combobox selection the one thread executes the following:
CONTROL SEND hDlg,%cmdStart, %bm_getimage,%image_bitmap,0 TO hBmp
CONTROL SET IMGBUTTON hdlg, %cmdStart,"#109"
deleteobject hBmp
Again, it works fine until another window opens which in response to WMPAINT
messages simply does "movetoex" and "lineto" drawing statements. It doesn't
use the above image but yet it seems periodically the CONTROL SET IMGBUTTON
function doesn't work as the button has no image. I don't use getdc() so
that doesn't explain it either.
------------------
[This message has been edited by Brent Boshart (edited May 24, 2000).]Brent BoshartComment
-
Are you testing the value of hBMP to indicate success of the %BM_GETIMAGE message, plus testing the return value from CONTROL SET IMAGE (add a TO RESULT& clause) ?
Error testing can often be helpful in these situations
Also, be sure you are not running low on resources or memory - try using TaskManager or Resource Meter to monitor your application for growing memory consumption problems.
------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>Lance
mailto:[email protected]Comment
-
Brent --
I listen a word "thread".
Do you start some instances of the same functions ?
If so, do use mutex/critical sections to make your app thread-safety ?
PS. Hope, that you didn't forgot to add Register None.
[This message has been edited by Semen Matusovski (edited May 25, 2000).]Comment
-
No I'm not testing hBmp and no resource leaks. I've run the program for hours and resource monitor stays the same.
The functions that the thread executes are unique to it.
------------------
Brent BoshartComment
-
Semen, I'm starting to get concerned at your constant and unnecessary warnings about using #REGISTER NONE. The reality is that there are so few problems and restrictions with register variables that using #REGISTER NONE is simply skipping an easy advantage that code can benefit from. It is not a problem if you carefully optimize the code yourself with the REGISTER statement (which is like a DIM statement, I'm not talking about the #REGISTER meta-statement)
So far the only confirmed problem with register variables (that I know of) is with the FLUSH statement... if you know of any others, I'd appreciate you posting them or emailing them to me. Thanks!
(Note that the current version of the compiler does not support register variables with the TO keyword, but this is set to change in future editions of the compiler)
Brent, try to test the ERR, etc, and let us know how you get on... until the exact location of the failure is known, debugging further will be difficult.
------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>Lance
mailto:[email protected]Comment
-
I would agree with Semen's warning. I sometimes get confounding and inconsistent problems with code that does not have #REGISTER NONE and uses DDT.
It works >=95% of the time, but strange difficult to track errors have occurred.
These problems magically disappear with #REGISTER NONE.
It could be that subtle bugs in MY code are exposed by #REGISTER DEFAULT, but I do not believe so.
The only example, that I can cite is that I used Dave Navarro's ASM code for File to MIME (Base64) conversion within my code and I would sometimes get failures.
Not all the time and definitely not the first time the code was invoked, but after a few calls to the subroutine.
When I used #REGISTER NONE on this program, It would not compile so I re-wrote the algorithm in straight PB.
Zero failures yet after two months of use.
IMHO, it is the combination of DDT and #REGSITER DEFAULT that may cause confounding/intermittent errors in my coding style, so I ALWAYS use #REGISTER NONE.
Just one man's opinion. I could be ME or ...
With my user base containing Pentium 166MHz through PentiumIII 700MHz, the minor processing improvements are not worth the hair pulling.
Joe Murphy
------------------
Comment
-
Folks, if you come across a problem which appears to be solved by #REGISTER NONE, then ...PLEASE... send it to us so we can see the problem and get the problem fixed!
Unfortunately, posting stories and heresay is counter-productive to both PowerBASIC and anyone casually reading these types of message. Reports of "spasmodic errors" and no compilable source code to investigate it is like a murder - but with NO body, No weapon, No location, No suspects and No clues...
Dave's ASM code that Joe mentions relies on register variables to operate, which is why it would not compile when #REGISTER NONE was used.
Thanks for your assistance with this matter, folks.
------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>Lance
mailto:[email protected]Comment
-
I know of at least one other person who have sent you codeOriginally posted by Lance Edmonds:
So far the only confirmed problem with register variables (that I know of) is with the FLUSH statement... if you know of any others, I'd appreciate you posting them or emailing them to me. Thanks!
which after your test (and advice) worked after #register none
was added.
This were ofcourse a "hard" compile-error..
So you have "at least" two confirmed problems...
But on the other hand, it depends on what meaning you put in
the word "confirmed"
But I tend to agree with all those members who recommend:
"better safe than sorry"
It cost a lot of money to be sorry
------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se
[This message has been edited by Fred Oxenby (edited May 26, 2000).]Comment
-
Compile time errors are a different issue... As I noted earlier, the compiler currently does not support register variables with the TO keyword.
So, I'll ask again... if anyone has any code that demonstrates what you believe is a problem with register variables, then please email it to us.
------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>Lance
mailto:[email protected]Comment
-
#register none didn't help my problem.
------------------
Brent BoshartComment
-
Brent, if you like, email me so I can see all of it and test drive
it and scan your lines for other clues.
It's not a request, just an offer to help.
Regards, Jules
mailto:[email protected][email protected]</A>Comment
-
This may not be the right question forum to discuss register variables, but the subject has raised so heatedly here it seems appropriate to add my comments. Firstly I must state I have no knowledge, directly or indirectly of register variables causing faults. rather I wish to constructively comment on Lance's statement that "that using #REGISTER NONE is simply skipping an easy advantage that code can benefit from."
Recently there was a forum discussion about register variables actually being slower than #REGISTER NONE. The conclusion seemed to sum up that it was machine dependant, order dependant and no one new why! This caused me to do some research in what little spare time I have. What follows is what I have found.
First, since the intoduction of the Pentium Pro the traditional Intel Architechture (AI not meening articifial intellegince!) registers are now called "retirement registers" and the detailed block diagram of the processor in the Intel Architecture Software Developer’s Manual shows a data path in but none out! The less detailed diagram shown later in the manual is hopefully more accurate and matches that of the AMD K6 2 manual. Basically these diagrams show that all data is pulled from the L1 cache and thus if you use a register variable it must first be loaded back into the L1 cache, requiring an extra clock cycle. This is obviously an overly simplistic comment as it would make indirect addressing via register inefficient as well as all the string instructions which use ESI and EDI. This is best summarised from this qute from the same manual "The IA’s register set can cause resource stalls due to register dependencies. To solve this
problem, the processor provides 40 internal, general-purpose registers, which are used for the actual computations. These registers can handle both integer and floating-point values. To allocate the internal registers, the enqueued micro-ops from the instruction decoder are sent to the register alias table unit, where references to the logical IA registers are converted into internal physical register references."
To summarise (and apoligies for such long windedness as it is a difficult subject) in all modern processors using out of order speculative processing the traditional AI registers are shadowed into multiple psuedo AI registers. If a close instruction requires a definative result in an AI register then the whole speed enhancing speculative process must close down and await that result, whereas if it were a memory sitting in the L1 cache the process would attempt to continue.
In the previous forum I refered to everyone missed that the original commenter was using an IBM/CYRIX processor which has a unique 6 way associative L1 cache (and relies on it). Neither Intel or AMD have to date IMO been able to match the speed of this processor at equivalent clock speeds for simple IA instructions (the FPU was a dog), which means that in the future they will attempt to.
Conclusion (finally): In traditional architecture designs the register variable was a superb enhancement, however in modern designs IMHO the default for future PB compilers should be #REGISTER NONE.
Regards
------------------
Comment
-
Guess what? My problem mysteriously disappeared. I hate when that happens as I'm always paranoid its going to raise its ugly head again when I least expect it! Oh well, at least it raised some interesting discussion about register variables.
------------------
Brent BoshartComment
Comment