Then you'll have to override WM_PAINT and figure out a way to hook into the underlying bitmap structure somehow. It was made clear early on that there's no direct support for this, nor any magical/secret method to do it. I know of a few ways that *might* work, but they're all fairly difficult to implement, wouldn't work across multiple versions of mIRC, etc., and are therefore not worthwhile to discuss/implement.
FWIW it seems to me that instead of finding a solution to a problem that actually works, you've already decided on a "solution" and are trying to retrofit it into your existing problem, whether it works or not. You're discovering that your solution isn't going to solve the problem, but you're too hell bent on your solution working that it seems to be "all or nothing". Perhaps you should step back and look at the bigger picture here, as other scripters in your position have done (DCX, MDX, et al.)
Is the goal of your project really to add more sophisticated drawing routines to mIRC? If so, adding new /draw3d* commands meets that goal. The suggestions provided by others in this thread also meet this goal. If you weren't so hard headed about implementing this without modifying any existing /draw commands, you would have already completed your goals. I'm sure you "like" the idea about not modifying /draw commands or not having to "reinvent the wheel", but are those your goals? Sounds like they are just side effects of one of your proposed solutions. If those are indeed goals, perhaps you should scale back, because as you've been told, they aren't feasible with mIRC's current architecture.
Also, as SBM has pointed out, you need to calm down. I highly doubt that turning this thread into a shouting match is going to get you a better answer.
