Is there a way to save your IAR window layout? Every time I start a debug session it fills my screen 9 different windows. I would be happy with 3 and a few tabs but I have to rearrange things every time. I don't see an obvious way to save them and Google doesn't have much to say on this either.
Related
I've been weighing the pro's/con's of making a gui app, and I've decided a console app is much more powerful for my calculator, especialy since it does different things like foil, quadratic equations, etc. So my question is make the console look like a gui based app?
The answer to your question depends on exactly what you mean by "console." If you're talking about Windows console windows, then the answer is "maybe." Some Windows installations can emulate VGA/EGA graphics within a console window, making them able to play old games for DOS.
Your mission would be to implement every GUI widget you need, such as clickable buttons, text-entry fields, etc. in terms of simple graphics primitives for drawing lines and rectangles. Then you have to write code that figures out where the mouse is and draws the mouse pointer in the right spot. You'd also have to write code to make the cursor blink, to make the arrow keys move the cursor, and to make it possible to select characters in a text entry box and copy, cut, and paste them.
When you got done, you'd have a program that works on some people's computers, but not on others. On some Windows installations, the console windows can't do graphics or go fullscreen. Your app wouldn't work at all on those systems, although you could write a fullscreen Windows app using a 2D game library such as SDL or Allegro instead of writing a console app, which would bring you back to the previous paragraph.
As you might have guessed by now, rolling your own GUI would be a whole lot more work than writing a Windows GUI program in which the buttons, text fields, etc are already implemented for you, the cursor already blinks, the mouse already clicks, etc.
Also, the code that does the actual calculations should be totally separate
from the code that gets the input from the user and puts the answers on the screen, so that code shouldn't factor into whether you want to write a GUI or a console app. They shouldn't even be in the same .cpp file as the I/O routines.
Now, some programmers use the term "console" to refer to xterm windows on Linux. These are not the same thing at all, and cannot draw graphics (and "console" is the wrong name for them to boot). But sometimes you see menus and stuff within them, "drawn" with colored text. Usually, these are drawn and managed using the external dialog shell command.
I'm writing a simple program in MFC that draws a a pattern according to a function.
I've added support for changing colors of the graphics. However, in the dialog, when the user tries to select the color button to see the color choices, the drop-down takes an abnormally long time to show up and appears frozen for about 5 seconds.
Nothing is being rendered in the meantime, nor are there any other obvious processes that might be slowing things down.
Does anyone know why this is happening?
What I need to do is create a program that overlays the whole screen and every 30 seconds the screen needs to flash black once.
the program just needs to be on top of everything, doesn't have to work over the top of games, but wouldn't say no if it did!
But i've got no idea where to start. Ideally the solution would be cross-platform for both windows and osx.
Does anybody have any ideas about where I should start or could whip up a quick demo?
OpenGL (you tagged it as such) will not help you with this.
Create a program, that overlays the whole screen,
The canonical way to do this is by creating a decorationless, borderless top level window with some stay-on-top property being set.
and every 30 seconds the screen needs to flash black once.
How do you define "flash back once"? You mean you want the display become visible for one single vertical retrace period or a given amount of time? Being the electronics tinkerer I am, honestly, I'd do this using a handfull of transistors, resistors and capacitors, blanking the analog VGA signal.
Anyway, if you want to do this using software, this is going to be hard work. If you'd do this using the aforementioned stay-on-top window, when you "flash" it away, all the programs with visible output would receive redraw events, which to process would take some time. In the best case scenario the system uses a compositing window manager which can practically immediately show the desktop. Without a compositor its going to be impossible to "flash" the screen.
Ideally the solution would be cross-platform for both windows and osx
A task like this can not be solved cross plattform. There's too much OS dependent work to do for this.
I presume this is for some kind of nerological or psychological experiment. I think doing this using some VGA intercepting circurity would be actually the easier, quicker to implement solution. I can help you with that. But I think there's another StackExchange better suited for this. Unfortunately digital display interfaces (DVI, HDMI and Display Port) use a complex line code scheme, which can not be blanked as easily as VGA, so you must have a computer capable of analog (=VGA) output and a display with a VGA input.
I'm working on a Qt project and I've noticed a persistent problem with some GUI forms. The form looks fine on KDE (bottom picture) and Windows , but when the app runs on anything GNOME3-based (like Unity or GNOME3 itself) some parts of the form are hidden from view. (Top picture, everything below the Sort Ascending radio button is cut off)
The problem seems to be with how Qt layouts handle large font sizes. If the user is using normal-sized system font (<= 10pt) everything works fine. If they are using larger fonts, the form is not large enough to accommodate everything. Other forms affected by this bug are merely crowded, but that isn't as serious as having vital controls out of bounds. The layout doesn't want to resize itself to take advantage of new space if I enlarge the dialog. Is there an easy way to make it do this or do I need to hard-code it? Originally the code prevented dialog resizing during runtime, but restoring that functionality didn't fix the bug. Even if the dialog can expand, the problem is the layout won't expand with it.
Up until now, I've made all affected forms oversized to compensate for this bug, but it looks strange to have the dialogs much bigger than they need to be on Windows and KDE systems where the font is the proper size. Is there a way to cause an affected dialog/layout to resize itself so everything fits properly at runtime? If so, how would the program detect it when parts of the GUI are out of bounds? I would prefer not to force a certain font size (some people may prefer large fonts due to vision problems).
Thanks in advance for help.
The fix for this is using a different approach when displaying forms. A more dynamic way as I'll describe. I've successfully used this approach on Windows with 96 and very high DPI modes (over 120).
1.
Query the OS and get the user's chosen font for a particular system item; say the font used for the window caption or system dialog boxes. Also you could allow the user to choose their font later if they desired. Use True Type fonts when doing this if possible.
2.
Using that font, construct a string object that you'll use for a label or edit control (I don't know what this is for QT, for Windows it is GetTextExtentPoint32) and pass it to a system function to determine the width and height of the string for your environment.
3.
Given the above value, place the control and dynamically resize the form with the padding all around the control as you like. For buttons you might always add a certain percentage of pixels above and below the button to taste.
4.
For graphical elements like Bitmaps and jpegs, again query the OS for the current DPI settings of the monitor and use larger, pre-made resources. Naturally, all text around theses elements will be dynamically placed on the fly.
Note that on Windows you'll need to mark your exe as high dpi aware using a manifest.
Tools like Fraps work with games based on OpenGL or DirectX but doesn't work with simple Windows 8 Metro style games like "Cut The Rope" or "Pirates Loves Daisies". Yes I know that "Cut The Rope" and "Pirates Loves Daisies" are using different technologies like JavaScript and HTML5 canvas but I'm really curious is it possible to build Fraps like tool for such games (some kind of canvas hack?). I would like to do 2 things:
1. Measure fps.
2. Capture screenshots.
I was reading articles about the whole Fraps concept and intercepting calls to DirectX but I'm not sure if its gonna work with Metro applications. Maybe I'm just wasting my time. I have 2 questions for you guys:
1. Do You think is it possible to build Fraps like tool that works with Metro style applications or games that are NOT using DirectX or OpenGL?
2. Does messing around with dxgi.dll (or other dll) could help somehow?
Thanks
Fraps is able to display the framerate because of hooks it has into DirectX. HTML apps do not provide access to this same information.
I've confirmed that the free program ScreenPresso (http://www.screenpresso.com/) can record Cut The Rope just fine.
Try Intel GPA (graphics performance analyzers)
http://software.intel.com/en-us/vcsource/tools/intel-gpa
Install it and then run the app.
There are a zillion options for graphs and stuff that I don't entirely understand (maybe it will be useful to you). If you want fps, just close the window; the program will continue running in the background.
There should be an icon in the lower right next to battery info and volume control. If you hover over it, it says your IP address. Right click on the icon for GPA and then select "Analyze Application" at the top.
A window will pop up with all the tile apps on the machine. Click on the app (don't double click) and click "run" in the bottom right.
The frame rate and resolution will be displayed in the upper left corner.
Tested and it works for Cut the Rope (I'm getting 58-60 fps). Hope this helps.