I'm drawing some graphics and text with GDI in my CScrollView. I need to implement the zooming functionality. I only need the zoom out functionality, no need to zoom in more than what is normally rendered.
Here are my best ideas:
Use MM_ANISOTROPIC mapping mode with SetWindowExt/SetViewportExt... The problem with this approach is that it does not scale text. Is there any way to force MFC to scale the text as well? Only thing I can think of is to set text font size according to the selected zoom value, but I'm not sure whether this will look well after all...
Draw to memory DC, and use StretchBlt to blit to the client area of appropriate size (set with SetScrollSizes...). This will solve the text scaling issue.
Also it is desirable to have antialiasing effect in the process. I think both methods above should accomplish this per se, but I don't know which will look better. Also I will have to implement printing/print-preview functionality later (using MFC's standard implementation from doc/view architecture), so I need the method to be compatible with that.
Need your advice please. Which way to go and why. Maybe other options exist too?..
You really don't want to mess with the mapping mode when you use MFC -- MFC itself already uses it for (at least) the print preview functionality.
I'd see if SetWorldTransform will work for you. At least with vector/TrueType fonts, it will scale the text along with everything else. Note that before SetWorldTransform will work, you need to call SetGraphicsMode with GM_ADVANCED.
I ended up using the second method I proposed in the question, but used DIBs instead of DDBs (and StretchDIBits() instead of StretchBlt()) because it proved to cause less problems, especially when using big bitmaps, and when printing.
Related
Is there any way to apply or have custom frames (images) around specific X windows?
For example, in xfwm4 and fvwm (window managers) it's possible to have a specific window decoration for a window with different images, one at the bottom, other at the top, etc. examples:
For xfwm4 and fvwm.
Obviously if it was that easy, I'd just use either of them, however, I do think that a singular program could handle it instead of needing to change the whole window manager.
I'm currently using dwm and there are ways to change the colour and thickness of border, and that's it. If I was better at C I could create a rule to draw images around specific X windows with specific WM_CLASS, but that's too much for me now, so any help is really appreciated.
An alternative solution would be to draw a single image (from a file) bigger than the X window behind it and make it to follow the X window position, and maybe the size as well (that's harder, so it's not really that necessary)
I started writing a C++ program to do that, but that may take too much time since C++ still a new tool to me and looking at how xfwm4 handles this.
I'm trying to graph some things in C++ and Koolplot seems like a very simple and suitable library to do so with. I'm stuck, however, on finding some documentation about it that allows me to fullscreen the application (or resize it like you can do so on lots of applications, chrome, word, discord...). As well as this, I can't find or see how i can allow the user to drag the graph around with the mouse as well as zooming into a point of a scatterplot or function. If anyone has any ideas about these things i'd appreciate it, thanks.
The short reply is: cannot do.
Koolplot uses for drawings of the charts a modernized version of the venerable BGI driver. It was invented once upon a time, when personal computers were still running on some DOS version. Those times the graphics were full screen, hence of fixed size. This particularity was kept in the modernized WinBGIm library.
Zooming or panning properly a chart present on the screen require access from the drawing/painting routines of Koolplot to the data to be shown. This is not the case. If you look once again in the source code, you will note that in the implementation efforts were made to keep separated data to be plot from the actual drawing on the screen.
In conclusion, to do what you want, you will have to modify WinBGIm such that it manages correctly a drawing surface of variable dimensions and modify koolplot such that data to be shown is owned by (or aggregated with) Plotstream class.
I need to implement a simple sound editor with a specific signal processing function.
I want to display the sound information vertically as a large picture - 1024 x [large height].
So I'm looking for Qt's best way to implement low-cpu-consuming vertical scrolling similar to web-browsers scrolling.
You need to create a custom widget by overriding it's paintEvent().
Have a look at this self-explanatory example on how to create a following widget.
A normal QScrollArea will give you what you want 99% of the time. But you're wanting to create a bitmap of potentially massive size, and you want to store it in RAM - you will quickly run out of space.
You are probably going to need a need a system where you save the image to file, and use the scroll area's bounds to intelligently load it's contents from the file (and a certain size around it to make it smooth) - Qt does not provide this. This is hardly groundbreaking stuff, so a web search for "scrolling very large images" or something similar should give a smart result.
If your intention is to plot STFT data, then you can easily adopt one of the widgets in the QWT library:
http://qwt.sourceforge.net/
Anyway, take a look at it, it is a great source of inspiration and the code is available...
Could anyone suggest me a particular way to implement animation in my Dialog-based mfc program? The animation that I am intending to add is like a construction digger machine graphic that would read the values of the machine parameters and change the shape of the graphic accordingly. Most of the information is read from a text file in terms of the parameters, so I just need to be able to get the animation working.
Thanks for your help in advance.
Well, GDI is easy but ugly and quite slow, GDI+ is also easy, but nicer although generally slower. OpenGL or DirectX are much, much faster but quite hard to program. Other libraries, such as cairo, are also available.
I'd suggest to start with the easiest (maybe GDI+) and see if it is fast enough for you.
Do do that, just Invalidate() the control where you are drawing in a timer, (or when you receive new data), and paint the whole graphic in the OnPaint() function. A basic improvement is to Invalidate() only the region where the new data affects the picture.
If then you notice that your code is not fast enough, come back and ask how to improve it. A concrete example will make it easier to get a more useful answer.
there are lot of articles. Most of them based on drawing in device context
http://www.codeproject.com/KB/GDI/flickerfree.aspx
http://www.codeguru.com/cpp/g-m/bitmap/article.php/c4879
http://www.codersource.net/mfc/mfc-gdi-plus/animation-control-mfc.aspx
I'm looking for a really good dialog resizer class that will stretch and shrink individual items as needed as the screen is resized. Stephan Keil has a good one (DlgResizeHelper) which basically resizes everything by a set ratio, but I'm looking for something smarter.
For example:
Icons should not resize
Single-line text boxes should not be stretched vertically
Buttons should probably stay the same size
Basically I'm looking for something to look at all of the controls, figure out that a static text field is related to a control next/below it and anchor the two together, and resize large controls in a 'smart' way so it looks good.
Are there such frameworks out there? I've been working on one but something ready-made would probably be better.
FOLLOW UP: I'm looking at the suggested solutions. Many of them require you to go in an anchor each control on the dialog. I'm looking for something smart that will figure out what the anchors ought to be, with the ability to manually anchor if the guesses are wrong. Seems like it should be possible -- most humans would agree a static text field next to an edit field should be anchored together. Guess I'm almost looking for a little AI here :)
You can use wxWidgets. It completely replaces MFC, is multi-platform, and gives you a layout-based dialog mechanism.
I use ResizableLib (also does PropertySheets and Pages) off codeproject, IIRC. You set anchor points that determine how the dialog and controls resize or move as the dialog moves.
You can set up to 2 anchors per control, (left, right) so you can move them as the dialog moves, or resize them as it moves. Its very easy to understand, if difficult to get perfectly right :)
I've tried many and finally settled on http://www.codeproject.com/KB/dialog/layoutmgr.aspx. It doesn't do the 'intelligent' layouting that you suggest though. I've never seen that in any library, on any platform - I don't see how it would work without having lots of under the hood magic that'd have to be overridden half of the time anyway.
The Ultimate Toolbox MFC library (here on CodeProject) includes a layout manager. I haven't used it myself, but it looks like it does what you want.
You can look at Professional GUI we use their class library for resizing our dialog controls. I think that is part of their free version.
We use CResize class from CodeGuru to resize all controls automatically. You tell how you want each control to be resized and it does the job for you.
The resize paradigm is to specify how much each side of a control will move when the dialog is resized.
SetResize(IDC_EDIT1, 0, 0, 0.5, 1);
SetResize(IDC_EDIT2, 0.5, 0, 1, 1);
Very handy when you have a large number of dialog controls.
Source code
This is a free solution also from CodeProject
http://www.codeproject.com/KB/dialog/dlgresizearticle.aspx
It's just a set of simple macros that position controls as the dialog resizes.
Edit - following the OPs comments. I don't know of any general sizer support like QT/WX for MFC, it doesn't seem to be present in new frameworks like Winforms either.
It is in QT/WX because it is necessary for multiplatform where widgets may be a different size, which explains MS lack of it. But it is also vital for multi-language ports, eg. where the German for cancel is 30 characters long.