I need to write some mathematical expressions (like a matrix and mathematical variables...) into my GUI.
The MFC static control is very limited on this issue. Especially for the math. symbols.
Is there any control or other way to make this happen?
You may want to check out MFC Grid Control:
http://www.codeproject.com/KB/miscctrl/gridctrl.aspx
There is only one good math editor, see http://www.dessci.com/en/products/mathplayer/ . It's not so much a ready-to-use control though, it may or may not work for your application.
Consider allowing TeX-style equations in your application. Again, depending on your audience, this may or may not be an option.
OK all I did now is a bit dirty, but I put everything with static controls together and changed the font to Symbol from microsoft to get the greek letters.
You maybe need to resize and move some of the controls but then everythings seems to work.
So all in all kinda dirty.
You can use calc from openoffice and save the formula like image. Then you can display it in your gui. I hope thet help you.
Related
I'd like to use tooltips with the same design as the error/validation tooltips (rounded box with a tip pointing to the mouse's position).
Given the name "error/validation tooltips", it bothers me to use them as normal tooltips.I haven't found people having the same "principles" issue as myself..
So, is it that bad to use the error/validation tooltips as normal tooltips? And, if yes, what would be the easiest way to re-use its design without rewriting much code?
Hope it's clear enough :) And that you will be able to enlighten me somehow in this matter :)
Regards.
BS_C3
Good or Bad is subjective based on what you're trying to do and the design of your app. There is never a right a wrong answer to stuff like that.
To reuse that design, you have two options that I see.
The first is to set the styleName of your toolTip component to errorTip.
The second is open up the default.css in the Flex Framework directory and copy and paste the CSS for the errorTip into your own CSS file that you then use in your application.
These docs will be good reading on this issue.
I still find myself hand coding Visual Studio projects more than using the variety of UI-driven menus and dialogs. For example:
web projects: hand code html/css in Source View vs dealing with the Design View / Properties Window
flushing out class files: code by hand using stuff like the prop-TAB-TAB Create Property keyboard shortcut and good ole Ctrl+[X|C|V] instead of the Class Diagram feature
Do I need to give the dialogs and menus another shot, or is this the current state of IDEs? Intellisense is the best thing since sliced bread IMO.
Steve
I'd be quite content to have Microsoft remove the design view from Visual Studio. I find myself cursing it every time I accidentally hit the button and wait ages for the broken rendering engine to kick in. This is from the perspective of a web developer mind you - I'm sure it's essential for developing windows apps.
Generally I think most of the RAD tools are not particularly useful, and in the long run end up being problematic as they're not very flexible. When developing web forms asp.net applications the listview and repeater are generally the only controls that I use. Hand coding html/css would be the preference for most designers anyway. Tools like Dreamweaver are nice initially when you're learning, but you do get to a stage where you realise you're using them as a glorified text editor.
Intellisense as you mention is utterly bad arse, and the one thing that I would miss if I switched to something like e or Textmate.
I am not a .NET programmer, and I understand Visual Studio does provide a lot of nifty code generation tools. However, I think it's rather important that a developer knows the code in his application. If you feel comfortable hand-coding it because you feel more in control that way, I don't think that should bother you at all.
Also, as someone who writes a lot of HTML/CSS by hand, I know that Visual Studio's Design View does not churn out 'quality' front end code a lot of the time.
I personally hand code html/css as well as my class definitions 99% of the time. Exceptions would be things that would be hard to hand-code otherwise (does anyone hand-code WCF proxies?)
It's all about YOU. What makes YOU more productive. What makes more scenes for YOU.
It's good to know and learn alternative ways to achieve your goal. You can give it try but if it slows you down return to the way YOU used to code.
I certainly find the the UI designer only works for the simplest of pages, and even for them only for a few design iterations. I find this for two reasons
1) When laying out a page, there are often several legitimate choices, and I don't like the choices VS makes. For instance, it will set the width of tables using pixel sizes, while for most fluid pages percentages make more sense. Nothing wrong with what it does, but for whatever reason I find myself fighting it more often than not.
2) It hard-codes a lot of style information, and even creates synthetic styles in an in-page style sheet. I'd rather have a concise and comprehensive CSS for the site as a whole, minimizing overrides on each page (or in each element!). Again, I fight it more often than not.
Well the designer for WPF/Silverlight is pretty cumbersome to use. So I pretty much hand code xaml and C#. At the moment I do not do much asp but with MVC, I would assume I would hand code that.
With visual studio having intellisense for a lot different syntaxes now, it is easier then ever to hand code, well, code. :) I mean intellisense works for C#, CSS, javascript, asp, and XML (if set up right). It is pretty easy to code now days. The youngsters have it so easy now days. They do not know how hard it was to code back in the day.
I'd say it absolutely, 100% depends on what you're writing.
If it's a basic CRUD interface for a simple database, then I'd say yes, 80% is way too much.
If it's a Web Application with plenty of JQuery UI and no persistent data source, then 80% is probably less than I'd expect.
As Vadium said, it also depends on what makes you more productive. Personally, I fly along with Intellisense, but I'm not too good on using UI tools to build an app.
I always feel dumber using Visual Studio, but I have to finish my project sometime this century to get paid.
I'm not sure if it will bring anything beyond saving on traffic through the removal of long-worded names, but I would definitely want to hide my system of namings, declarations and their organization.
The thing is that manual Find&Replace is going to take a very long time, and each slight modification could probably require the process to be redone in part or in whole.
Has anyone thought of this problem? Maybe write a macros? Will it be intelligent enough to be able to discover names in a CSS file? Does anything better and simplier exist?
You can't make it "unreadable", but you can save some space by using things like the CSS optimizer
You might want to try YUI Compressor:
http://developer.yahoo.com/yui/compressor/
Firstly I don't think I would do it at all, what exatly is to be gained by making it less readable?
But if one had to do it, why not make a custom parser that would convert your "development" names to "production" names and vice versa as needed?
Use Perl. A simple perl script can search through all of your files recursively and replace whatever you specify with something else.
Use a CSS compressor. It will make it really hard to read, but it's not possible to make it completely unreadable. Here's one from CSS Drive.
As others have stated, you can make the names shorter or less meaningful, but to reach a human-unreadable state is essentially not possible.
No matter how you rename or distort the css, it still has to have proper atributes and the html has to reference the named classes and/or ids.
Additionally tools like firebug will unfailingly point users to the css being used which I assume will defeat your intent.
It also defeats the purpose of using semantically meaningful tags in your html.
I am a newbie at Flex, and I don't like the way you have to write the namespace mx: for every control declaration you write. It makes the code cluttery. I would like to write:
<Panel ...
rather than
<mx:Panel ...
I tried writing
xmlns="http://www.adobe.com/2006/mxml"
for the top level element instead of
xmlns:mx="http://www.adobe.com/2006/mxml"
In the top level declaration. This work to an extent, but broke some existing code. For one, XML data that are defined in the document are all appended with aaa: as the namespace during runtime. I've also noticed other issues in my very small sample program.
Is there a way to do this that works, or is this a lost cause? And some background information on why would be appreciated.
Update: Thanks all for the replies, but I would like to have heard from someone who actually tried this and thought it was important. Although most of you told me it was a bad idea, I was not discouraged. I got a couple of programs working this way smoothly now. And plan to do this in all my flex apps. One trick seemed to work for me although I can't claim it'll work universally. If you need separate namespaces within your doc, take, HTTPService parameters for example, you could create a namespace within that element like so:
<HTTPService id="service" url="http://blah.com"
method="POST" result="gotResult(event)">
<request xmlns:p="*">
<p:param1>p1</p:param1>
<p:param2>p2</p:param2>
</request>
</HTTPService>
Hope this helps someone. I am very happy with how clean my code is now, almost as clean as a normal html file. As for people who think writing mx: throughout your code is clearer and what not, I disagree completely. I think languages that require you to repeat the same character sequence excessively in your code - which you should consider a document - have design flaws. Here's an analogy for you: how would you like it if you were reading an article on Barack Obama, and every single sentence contained the words 'Barack Obama', that would get pretty tiresome wouldn't it?
I think that removing the mx namespace will almost certainly cause you trouble with name conflicts as your project gets larger.
Personally I think the mx namespace makes the code clearer rather than more cluttered, especially if you have component based flex development or a lot of your own controls. Having owned a large flex code base for the last two years I find the mx namespace unobtrusive, especially when you have custom objects embedded inline such as item renderers.
My recommendation (unscientifically asserted) is to put up with it, especially if you are finding issues when removing it. I bet you'll stop noticing it after a while.
You need the mx or some xmls:[SOMETHING HERE] because that's the XML namespace that refers to the definition of the controls. It's like using namespaces in normal code.
Just writing Panel is ambiguous and could possibly conflict with another person's implementation of Panel. So we declare to Flex what namespace Panel belongs to (http://www.adobe.com/2006/mxml) and we alias it with mx.
Microsoft's WPF XAML requires this as well.
Just to be the voice of dissension...
In digging through Ely Greenfields code he does that a lot - I'm not sure if the other developers on the Flex SDK team do that but it does lend some credence to the argument for doing it...right?
I agree with the majority of other answers here, it is best to leave it. Eventually you will be wanting to use other namespaces for things such as custom components and you will need a namespace then for making the distinction. Then you will have some with a namespace and some without.
I would say if for no other reason, you should leave it because someday someone else might have to look at your code and they are probably going to find it much more readable with the mx than without.
The mx: is just a way to tell Flex that the Panel (along with any other component) is a part of the Flex framework, that it, built-in in Flex. This helps Flex to know where to look for the Panel, and will make your compiling process faster.
You can also use local: to access components that YOU created. Example: If I want to add some functionality to my Panel, I would type some code, and save it as a customized Panel, dubbed MyPanel. Them, I can use to tell Flex that MyPanel is my component, and it can find if somewhere in my project. Of course, you can name it anything you want :-)
I agree with you that the mx: looks unsightly at first, especially when you already have a strong background in HTML or XML, but you'll get used to it.
Keep in mind that if you are developing applications that should run on all kinds of platforms including mobile devices it is best to stick with pure spark as far as possible as it is supported on most mobile devices these days. There are cases where one is forced to use an mx control like an Accordion for instance. In this case if you do have time to implement it, it is wise to use tools or the basic controls in spark to create these more advanced or complicated controls to use instead.
Has anybody experience in building a custom style in Qt? What I have in my mind is a complete new style that affects all kind of widgets. I have seen some examples in the web for a custom combo box. But I have no idea how much time and code it takes to build a "complete" new custom style ... maybe someone can give me a hint.
We think of using Qt 4.3 (or even newer) ...
Check out the Stylesheets facility in Qt 4. While it's still a hassle, it's way easier than doing a full-on custom style. You can just adjust one visual facet at a time and try it out.
It pays attention to inheritance. So if you style the font in QWidget, then every visual widget will also use that font. And so on.
I have developed a "new" style that changed the appearance of much of an application. It did take some time, and quite a bit of experimentation. I also derived my style from the generic windows style, to allow it to handle some of the stuff I didn't want to mess with. All told, I think it took me a week to get most of what I wanted, with practically no prior exposure to the styles.
In order to actually develop one, I would get into the source for their styles example, which has a "wood" style. I put my own style in place of the example style, and started changing things while using the example program to check how it looked. Depending on how you are developing it, you might want to have a configuration file so you can easily change some of the values without recompiling.
You might want to look at existing styles. You can find quite a few of them on kde-look.org, in the Styles / 4.0 section.
We've done it in the past (in Qt 3), and it's extremely time-consuming. We had a lot of problems with flickering, redraws not working the way we expected, sluggish behavior, bugs in the Qt implementation. It a lot less straight-forward than it seems, and there's little support or user experience too. Unless you need something really particular (as we did), I'd say it's not worth the trouble.
Other frameworks are supposed to make it easier (some Java-based?), but I don't have first hand experience.
If you don't need to radically change the widget style, you might want to try using widget style sheets:
http://doc.qt.digia.com/4.4/stylesheet.html