I wonder if it is possible to embed dynamic text into Keynote'09? I want to create a new presentation and run this presentation with different text messages (depending on the time of the day and day of the month).
You can insert formulas in tables. I don't have the english version of keynote open, so I can't tell you the exact names of the functions (guessing). You can do something like
=IF(MINUTE(NOW()) > 30; "> 30" ; "<= 30")
See the formula help. If you tell me what you want to achieve, I can give you further details.
I'm not aware of any direct or easy method to achieve what you are asking for.
However, with AppleScript you can access and change at least the title and the body boxes of the slides. This should be done prior to the presentation.
If the 'dynamic' text is to appear in a text box, you could use some scripting to modify the presentation's XML directly. An older Keynote's XML schema should be reasonably well (but not wholly) documented in the iWork Programming Guide, but as the '09 file format is not backwards compatible I don't know how much that would help.
You could try using an encapsulated post script image file. Postscript is a real programming language. I don't know if Keynote will accept it (or if it will cache a bitmap), but Cocoa loads EPS, and Keynote is cocoa.
On Mac OS X, an EPS file gets evaluated when it is opened and converted to a PDF in memory. This process can take a really long time, like 30 seconds, if this is the first time you've tried to open an EPS file since logging in.
Ah! Someone pointed out to me that you can embed Quartz Composer compositions into keynote. This is a good way to do it.
Related
First off I've searched my hind end off for hours now trying to find an answer, but I can't seem to find anything remotely useful. What I am trying to do is to find a way to add in code-folding to the built in batch language. Basically I love using batch, but when I have tons of code, I want to be able to hide the code I do not need to edit which will make it easier to find the code I DO need to edit. What I want is to be able to make it so if I typed "::{" (without quotes) and have finished code in the middle and end with "::}" (also without quotes).
First question, is it possible? Can I add something like this (that one could normally add in the "user defined language") to the built-in batch language?
Next question, if not, where could I figure out how to basically re-create the batch language (and add my own twists) into a new "user defined language"?
Last question, if neither of those are possible, what are my other options?
Like I said, I've researched for hours. I'm not one to ask for help on forums, but I'm desperate at this point. All I want is to use the batch language and have code folding. Doesn't seem like too much to ask, but it might be!
Thanks!
In Notepad++ you can define a language by going to the Language menu --> Define your language (at least in version 6.6.9 anyway). On the Folder & Default tab, under Folding in code 1 style, input a ( into the "Open" box. Input a ) into the "Close" box. Save this as "Windows Batch" (or at least something that doesn't conflict with the in-built language named "batch".
Until you define styles, it'll be ugly and unusable, but it should allow you to collapse / expand parenthetical code blocks as a proof of concept and see whether this project is worthy of further effort. Your next steps will be to copypaste batch keywords from %PROGRAMFILES(x86)%\Notepad++\langs.model.xml, and use the "batch" language styles from your favorite theme in Notepad++\themes\. If I were doing it, I'd input a few basic things using the GUI (like keywords, folding characters, etc.), then export to an XML file on the Desktop and copypaste the rest from a theme, search-&-replacing stuff as needed to massage the theme into your user-defined language. At the end, import your massaged XML into the Define your language dialog. It was going to be more effort than I felt like exerting, but your mileage may vary. If you decide to undertake this journey and you complete it, I hope you'll consider sharing your efforts.
This similar question has a few answers that suggest some workarounds you might find worthwhile -- in particular, hiding, rather than collapsing.
I have the following question:
The calendar text file and binary file should have a name that with a fixed part and a variable part. Use the time function (in time.h) or some other automatic mechanism to make sure that, when you write the files back out after updating the calendar, you do not overwrite the files you read in but you write a new version of the file that is clearly more recent.
Knowing that I have a program that manages a calendar.
Is it possible to to create a file with a fixed part and a variable part using the time.hlibrary ?
Thank you in advance!
Your question is vague, so the answer could only be similar.
From your specification, I guess you need a filename, f.e. "calendar-YYYYMMDDhhmmss.bin" and "calendar-YYYYMMDDhhmmss.txt"
When you "man time.h", you can see, that the time-"library" provides all these data. At the bottom of the man-page you see some related functions like "time()" and "strftime()", which help you to get a timestamp and to format a time to your needs.
If you "http://www.whathaveyoutried.com" and are stuck again, please update your question, and we will help you further.
EDITH (to the comment):
That depends on whether you should have a lot of files with each containing one "calendar" and the most recent dateded file is the actual calendar and the olde ones are backups; or you have one calendar-file with a new section for each "calendar", then you have to define (for yourself) how to organise these actual and historical sections.
as a matter of fact i would prefere the first solution, so each time you update your calendar, you call "fopen(path_filename_timestamp_txt, "w");". In the second case you would call "fopen(path_filename_txt, "a");" and "fwrite(timestamp);" your section-header;
Please show us, what you have done so far! (as short as possible, according to http://sscce.org/)
This is in C Language
I want to know how i can write a program to lookup all the input fields of a website. Any website. and then can fill them in. I can write the simple webbrowser in vbs but how can i analyse the input fields. even better would be is i could click the lookup field and it puts the name of it in a box..... that would be ideal.
Anyone can help? thanks :)
Are you sure you want to do this in C?
I ask because it is not easy. First of all, you need to be able to run the HTTP GET request against the webpage you wish to view. For this, you probably need libcurl; you definitely don't want to be writing from scratch at any rate.
Next, you need to process the html you get, finding all input fields. You do NOT want to do this using regular expressions, if anything for the sake of bobince's blood pressure. HTML is not a regular language is the bit you need to take away - you need an xml parser. Enter libxml. I'm sure there are other xml libraries out there, and even libraries for parsing html.
Finally, having done that (got the fields etc) you need to be able to populate them and submit the correct request as per the ACTION and METHOD parameters of the FORM.
This is of course assuming you know what the fields should be formatted with. And it also assumes nothing else is going on. If you have a javascript validated web form (I sincerely hope they're validating on the request too, but they might provide feedback via JS) you won't benefit from that (unless you're going to integrate JS, in which case you might as well write a browser).
This is not a trivial task and it is the reason there are accessibility standards for HTML, because otherwise it becomes tricky to interpret the form without human interaction.
Of course, this all assumes said html is well formed, which isn't always the case...
I might suggest another approach. BeautifulSoup is a well known Python web scraping library that works very well. Python as a language allows easier string manipulation too, which will dramatically cut down your development time. I'd suggest giving the need to use C some serious thought given the size and complexity of the task you want to undertake vs your need to get a result quickly. If you have a lot of time, by all means go for C.
I want to be able to read the content of pdf files. I need to do that with C on Linux.
The closer i can get to this was here but I think Haru can only create pdf and is not able to read them (not 100% sure).
PS: I only need the plain text from pdf
Check out libpoppler. I've never used it work extracting text, just querying PDF attributes. It's pretty easy to use.
How well do you need to parse them?
Just extracting strings should be relatively easy, fully accurate rendering is harder.
Take a look at the source for evince or ghostscript?
This is for C++ but might be a good starting point for understanding PDF structure http://www.codeproject.com/KB/cpp/ExtractPDFText.aspx (sorry wrong link before)
Another possible, though I've never used it is VersyPDF. It claims to allow you to edit PDFs ... http://versypdf.sybrex-systems-ltd.qarchive.org/
So we are sure that we will be taking our product internationally and will eventually need to internationalize it. How much internationalizing would you recommend we do as we go along?
I guess in other words, is there any internationalization that is easy now but can be much worse if we let the code base mature and that won't slow us down very much if we choose to start doing it now?
Tech used: C#, WPF, WinForms
Prepare it now, before you write all the strings in the codebase itself.
Everything after now will be too late. It's now or never!
It's true that it is a bit of extra effort to prepare well now, but not doing it will end up being a lot more expensive.
If you won't follow all the guidelines in the links below, at least heed points 1,2 and 7 of the summary which are very cheap to do now and which cause the most pain afterwards in my experience.
Check these guidelines and see for yourself why it's better to start now and get everything prepared.
Developing world ready applications
Best practices for developing world ready applications
Little extract:
Move all localizable resources to separate resource-only DLLs. Localizable resources include user interface elements such as strings, error messages, dialog boxes, menus, and embedded object resources. (Moving the resources to a DLL afterwards will be a pain)
Do not hardcode strings or user interface resources. (If you don't prepare, you know you will hardcode strings)
Do not put nonlocalizable resources into the resource-only DLLs. This causes confusion for translators.
Do not use composite strings that are built at run time from concatenated phrases. Composite strings are difficult to localize because they often assume an English grammatical order that does not apply to all languages. (After the interface design, changing phrases gets harder)
Avoid ambiguous constructs such as "Empty Folder" where the strings can be translated differently depending on the grammatical roles of the strings' components. For example, "empty" can be either a verb or an adjective, and this can lead to different translations in languages such as Italian or French. (Same issue)
Avoid using images and icons that contain text in your application. They are expensive to localize. (Use text rendered over the image)
Allow plenty of room for the length of strings to expand in the user interface. In some languages, phrases can require 50-75 percent more space. (Same issue, if you don't plan for it now, redesign is more expensive)
Use the System.Resources.ResourceManager class to retrieve resources based on culture.
Use Microsoft Visual Studio .NET to create Windows Forms dialog boxes, so they can be localized using the Windows Forms Resource Editor (Winres.exe). Do not code Windows Forms dialog boxes by hand.
IMHO, to claim something is going to happens "in a few years" literally translates to "we hope one day" which really means "never". Although I would still skim over various tutorials to make sure you don't make any horrendous mistakes. Doing correct internationalization support now will mean less work in the future, and once you get use to it, it won't have any real affect on today's productivity. But if you can measure the goal in years, maybe it's not worth doing at all right now.
I have worked on two projects that did internationalization: a C# ASP.NET (existed before I joined the project) app and a PHP app (homebrewed my own method using a free Internationalization control and my own management app).
You should store all the text (labels, button text, etc etc) as data inside a database. Reference these with keys (I prefer to use the first 4 words, made uppercase, spaces converted to underscores and non alpha-numerics stripped out) and when you have a duplicate, append a number to the end. The benefit of this key method is the programmer has a pretty strong understanding of the content of the text just by looking at the key.
Write a utility to extract the data and build .NET resource files that you add into your project for compile. Create a separate resource file for each language. In your code, use the key to point to the proper entry.
I would skim over the MS documents on the subject:
http://www.microsoft.com/globaldev/getwr/dotneti18n.mspx
Some basic things to avoid:
never ever ever use translation software, hire a pro or an intern taking that language at a local college
never try to create text by appending two existing entries, because grammar differs greately in each language, this will never work. So if you have a string that says "Click" and want one that says "Click Now", do not try to create a setup that merges two entries, or during translation, copy the word for click and translate the word now. Treat every string as a totally new translation from scratch
I will add to store and manipulate string data as Unicode (NVARCHAR in MS SQL).
Some questions to think about…
How match can you afford to delay the shipment of the English version of your application to save a bit of cost internationalize later?
Will you still be trading if you don’t get the cash flow from shipping the English version quickly?
How will you get the UI right, if you don’t get feedback quickly from some customers about it?
How often will you rewrite the UI before you have to internationalize it?
Do you English customers wish to be able to customize strings in the UI, e.g. not everyone calls a “shipping note” the same think.
As a large part of the pain of internationalize is making sure you don’t break the English version, is automated system testing of the UI a better investment?
The only thing I think I will always do is: “Do not use composite strings that are built at run time from concatenated phrases” and if you do so, don’t spread the code that builds up the a single string over lots of methods.
Having your UI automatically resize (and layout) to cope with length of labels etc will save you lots of time over the years if you can do it cheaply. There a lots of 3rd party control sets for Windows Forms that lets you label text boxes etc without having to put the labels on as separate controls.
I just starting to internationalize a WinForms application, we hope to mostly be able to use the “name” of each control as the lookup key, without having to move lots into resource files etc. It is not always as hard as you think at first….
You could use NGettext.Wpf (it can be installed from NuGet, and yes I am the author, but I made it out of the frustrations listed in the other answers).
It is hosted this github repository, and here is the getting started section at the time of writing:
NGettext.Wpf is intended to work with dependency injection. You need to call the following at the entry point of your application:
NGettext.Wpf.CompositionRoot.Compose("ExampleDomainName");
The "ExampleDomainName" string is the domain name. This means that when the current culture is set to "da-DK" translations will be loaded from "Locale\da-DK\LC_MESSAGES\ExampleDomainName.mo" relative to where your WPF app is running (You must include the .mo files in your application and make sure they are copied to the output directory).
Now you can do something like this in XAML:
<Button CommandParameter="en-US"
Command="{StaticResource ChangeCultureCommand}"
Content="{wpf:Gettext English}" />
Which demonstrates two features of this library. The most important is the Gettext markup extension which will make sure the Content is set to the translation of "English" with respect to the current culture, and update it when the current culture is changed. The other feature it demonstrates is the ChangeCultureCommand which changes the current culture to the given culture, in this case "en-US".
I also highly recommend reading Preparing Strings from the gettext utilities manual.
Internationalization will let your product be usable in other countries, it's easy and should be done from the start (this way English speaking people all over the world can use your software), those 3 rules will get you most of the way there:
Support international characters - use only Unicode data types in files and databases.
Support international date, time and number formats - use CultureInfo.InvariantCulture when storing data to file or computer readable storage, use CultureInfo.CurrentCulture when displaying data or parsing user input, never do your own parsing, never use any other culture objects.
textual data entered by the user should be considered a black box, don't try to break it up into words or letters, especially when displaying it to the user - different languages have diffract rules and the OS knows how to display left-to-right text, you don't.
Localization is translating the software into different languages, this is difficult and expensive, a good start is to never hard code strings and never build sentences out of smaller strings.
If you use test data, use non-English (e.g.: Russian, Polish, Norwegian etc) strings.
Encoding peeks it's little ugly head at every corner. If not in your own libraries, then in external ones.
I personally favor Russian because although I don't speak a word Russian (despite my name's origin) it has foreign chars in it and it takes way more space then English and therefor tests your spacing too.
Don't know if that is something language specific, or just because our Russian translator likes verbose strings.