Forums Developers Khaled, How does picture windows work?

I've been trying to implement some other drawing routines to mIRC with a dll, For the life of me, I can't make any GDI+ updates to a window stay, or get saved with a /drawsave

Basically what I did is use $window(@window).hwnd to then enumerate child windows, which there is one, a static control which I assumed was the correct surface to draw to. Drawing commands work, I see my changes, but any action that constitutes a WM_PAINT to the @window loses my changes, and even if I don't move it or whatever, a /drawsave doesn't capture any of my dll draws to the window.

My guess is that mIRC uses that compatible bitmap from the static control to do all its drawing to, and then blits the bitmap to the static control to reflect the updates, and a WM_PAINT just re-paints the stored bitmap. A drawsave also just converts the bitmap to the specified file extension and writes it to file.

Anyways, more to the point, if my guess is correct, how would I find this bitmap so my dll can draw to it?

Can you not draw your updates to your own HDC, and then move everything over to the @window's HDC whenever a WM_PAINT fires?

I'm not a graphics programmer so I have no idea whether this will cause flicker or any other issue.

The problem with that is, even if i have a compatible bitmap with a transparent background, overlaying my bitmap onto the @window with a WM_PAINT will cause ill effects, such as if a mirc /draw command is meant to cover a dll's draw, since the dlls draw is overlayed, it won't be erased by mircs /draw, and also a /drawsave doesn't take whats actually on the @windows child static controls dc, it takes from the compatible hidden bitmap and converts to an image format so anything drawn with a dll won't show up on a saved image.

As I mentioned on IRC, I don't see any reason why you *must* use /drawsave.

If you're adding functionality via a dll to extend picwins, it seems reasonable to have an extra save functionality to save those extended picwin buffers.

/mydll.drawsave { dll MYDLL DrawSave }

As far as managing WM_PAINT calls, it's feasible to overlay a window and still handle the calls coming from mIRC's native /draw commands. It's not trivial, but it's possible, and that's what you should be focused on. How? Well, there are plenty of docs on subclassing and hooking in MSDN.

I'm not too sure what you're trying to get out of this thread. You seem to know pretty much all there is to know about how the windows work. I doubt Khaled can add much to this-- there's no magic repository of information that would make subclassing the window any simpler. As you have probably figured out on your own (and as I mentioned on IRC as well), the buffer mIRC uses to store the actual image data is probably some internal data structure that you do not have access to. It's unlikely you'll get access to this data structure, so you have to treat it as a black box and deal with the WINAPI interface as any extension code would. This means subclassing the static control or hooking into its MessageProc, handling the WM_PAINT calls and injecting your own logic there.

I just figured with bw and bh for bitmap width/height was already there, somewhere theres a reference to an actual bitmap, maximize a window and draw to it sometime and try to go off-screen, you'll see it stops at where the bitmap is, which is why I think that its a singular bitmap manipulated and blitted to a window.

That's right, mIRC uses an internal bitmap and blits it to the window when necessary. I considered adding an .hbm property at one point to allow scripts direct access to the bitmap, however that would not have worked very well since your updates to the bitmap would not have been synchronized with mIRC's own updates.

The only solution I can think of would be for mIRC to add a bitmap update event for @windows. mIRC would update the bitmap, trigger an event to allow you to modify the bitmap, and then paint the result. That said, the /drawing commands update a number of internal variables regarding each bitmap, so that would also be problematic.

You could just implement your own draw* commands in the dll.

Seems like you're trying to extend picture windows anyway, why not just add your own functions? You could even alias them in mIRC so that they use the same syntax as the existing commands.

That's what I said

the whole point of asking is so that mirc and the dll work TOGETHER, so any mirc commands can be used, and any dll commands can be used to modify the same surface, so any drawcopy, drawsave, drawrot, whatever works on whatever the dll has already drawn to the surface.

I AM NOT TRYING TO OVERRIDE MIRCS DRAWING COMMANDS! I've already considered the suggestions but it is NOT what I was trying to achieve. I'd appriciate if y'all stayed on topic.

I'm working on implementing various 3D routines into mIRC and the fastest method thus far has been doing the mathematics within the DLL and only issuing /draw commands needed, even doing so is slow cause I can't keep what I draw on the surface any other way or it'd be even faster.



Texturemapped surfaces are the most taxing, the slowest, because the perspectively coorected affine texture mapper routine rasterizes triangles pixel by pixel drawing straight lines following two slopes.



This is a COMPLEX rendering of an object with 2157 points and 4002 triangles (faces) and some pseudo shading, it's not quite working correctly but it's getting there.

Nobody told you to override mIRC's drawing commands. The suggestion was to *add* commands as any script would and implement *new* custom drawing commands through your dll.

There's no reason why you need to issue *ANY* of mIRC's /draw commands to get what you need. In other words, just because mIRC has /drawrot, for example, doesn't mean you HAVE to use it. Implement your own /draw command: /draw3drot that would take similar parameters and perform rotation. Same for /drawdot, etc.

It will save you the time of having a pointless technical discussion about trying to hack into mIRC's internal data structures, or overriding message procs to get what you need. In short: it's simpler.

DCX does the same thing. Although the script is an "extension" of dialogs, it doesn't actually override any /dialog commands or events. Instead, it creates a new set of commands and events (/xdialog, etc.). There's a reason they didn't bother hooking into all of mIRC's controls. In the end, users don't care. A command is a command, whether it is built-in or added by script. You should take a page from DCX development and do the same.

once again, the GOAL OF THE WHOLE PROJECT is to aid in more sophisticated drawing routines to mIRC that would cause mIRC to freeze otherwise actually scripting them. I'm not trying to "re-invent the wheel" so to speak replacing commands mIRC already has. It's meant to provide more features to whats already there. The only way for them to work in unison is to modify the same bitmap mIRC does so everything /draw wise still works.

Bottom line, its my project, its what I want to achieve, and it will never be anything else, say what you want, suggest what you want, it's not happening. you want the changes? do it yourself.

I like the idea of it working seamlessly with mIRC's actual /draw commands and its own internal drawing commands. The whole deal is so that there is no special drawsave or anything of the likes, all of mIRC's commands will still manipulate the same blitted bitmap.

Again, if you have something USEFUL to add, please feel free. Suggestions on changing the initial concept are pointless.

Calm down. People were simply trying to suggest a way you could move forward with your project. If you don't want to do it "that way" that's fine, but in that case it seems you're going to have to accept that you've reached an impasse in development and unless Khaled implements some practical method of allowing direct access to the underlying picwin bitmap you're not going to get much further.

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.

I'm content with waiting on a viable solution and I really like khaleds suggestions, its hijackers like you that tick me off to no end.

You feel like your gods gift or something and its really quite obnoxious. The topic was even aimed at the creator of mIRC yet you decide to hijack it anyways.

I enjoy on-topic suggestions, be it features, questions, or of the like I really like to read what people have to say, telling me how to code my project is totally off topic and unwanted. If you think you know it all, why not make it yourself instead of telling me what to do? Put your money where your mouth is and do something pro-active besides babel about how you feel everyone should code.

Sorry, but when a user asks how to solve a problem, I usually take it to mean they want suggestions as to how to solve their problem. Therefore, suggesting how to solve your problem ("code your project") seems completely reasonable to me. When offering a solution to a problem, I leave every option on the table. You should too. This includes scaling back your expectations. I apologize if I didn't initially realize you were too hard headed to allow for this option. I see now that your goal isn't to actually add extra functionality to mIRC, but instead to perform a purely technical exercise in extending mIRC's internal implementation and builtin commands without any change to the existing API.

FWIW I've already offered countless suggestions that meet your goals.. why don't you put *your* "money" where your mouth is and start getting to work on implementing them rather than waiting indefinitely for a "viable" suggestion? You've already been told by Khaled himself that you basically have no alternatives. Why are you still "waiting" for an answer?

Just as a sidenote, I wouldn't hold my breath for Khaled's suggestion. First off, it's not yet implemented, so that makes it rather useless to you. Secondly, even he acknowledged many critical flaws with the suggestion, so it doesn't seem very likely that it will ever be implemented. Of course, you're free to continue waiting on mIRC updates.

I think Talon already explained the motivation behind his method and I agree, maintaining compatibility with built-in mIRC commands would have been a nice feature worth some extra work.
99% of mIRC projects are just a hobby, which makes it more than reasonable he tries to avoid spending his time with implementing all the rather boring drawing basics.

Anyway, the screenshots look interesting and I hope you will eventually find a way.