I'm looking for a Windows C++ (or a Embarcadero Delphi/C++ Builder VCL component) GUI component for a professional looking Hex Viewer/Editor. While pretty easy to build up a rudimentary one I require a polished modern looking component. (Can handle arbitrary amounts of data, loading from some sort of stream as needed. Colors/Fonts customizable. Highlight byte selections/individual bytes)
2 of the more usable hex viewer/editor components from applications I've seen in action are below:
http://niiconsulting.com/checkmate/wp-content/uploads/2009/10/fileinsight-2.jpg
http://www.the-interweb.com/bdump/hexer/hexer-linux.png
Can anybody recommend anything?
Thanks in advance.
After a quick search on the interwebs, I found the following component for Delphi:
http://www.tkweb.eu/en/delphicomp/khexeditor.html
QHexEdit2 is now able to edit large files (> 2 GBytes) and is available for Qt4, Qt5, PyQt4, PyQt5. It is now hosted on Github
https://github.com/Simsys/qhexedit2
You didn't mention Qt as an option as a C++ library to use. But it sounds like your circumstance may be flexible. So if you're able to use it there are a couple of options I noticed.
There's a hex component that you can drop in as a replacement for QPlainTextEdit or whatever:
https://github.com/Simsys/qhexedit2
The webpage for that says that the size of data has in general to be below 10 megabytes. A heavier-weight paging solution exists as a program called LFhex (source in the download)
http://stoopidsimple.com/lfhex
Related
I'm building a barebones Notepad-styled project (console-based, does not have a GUI as of now) and I'd like to track, display (and later use it in some ways) the number of times the console application has been launched. I don't know if this helps, but I'm building my console application on Windows 10, but I'd like it to run on Windows 7+ as well as on Linux distros such as Ubuntu and the like.
I prefer not storing the details in a file and then subsequently reading from it to maintain count. Please suggest a way or any other resource that details how to do this.
I'd put a strikethrough on my quote above, but SO doesn't have it apparently.
Note that this is my first time building such a project so I may not be familiar with advanced stuff... So, when you're answering please try to explain as is required for a not-so-experienced software developer.
Thanks & Have a great one!
Edit: It seems that the general advice is to use text files to protect portability and to account for the fact that if down-the-line, I need to store some extra info, the text file will come in super handy. In light of this, I'll focus my efforts on the text file.
Thanks to all for keeping my efforts from de-railing!
I prefer not storing the details in a file
In the comments, you wrote that the reason is security and you consider using a file as "over-kill" in this case.
Security can be solved easily - just encrypt the file. You can use a library like this to get it done.
In addition, since you are writing and reading to/from the file only once each time the application is opened/closed, and the file should take only small number of bytes to store such data, I think it's the right, portable solution.
If you still don't want to use a file, you can use windows registry to store the data, but this solution is not portable
What is the best way/common practice for maintaining all string resources found on a UI in Qt, especially the textual input/text in combo boxes etc. (since these are the once that are frequently used in the code itself)?
I know that Android has this string resources thing such that resources only have to be modified at one position.
Does Qt have something like that too or do I have to initialize string resources in code instead of in the UI's XML itself...
AFAIK, there is no built-in mechanism for string resources in Qt. If you want to maintain strings at build time you can define them in one .h/.cpp file as global variables and reuse them in your code.
Otherwise you can use Qt's translator files (binary) and load them along with your application. If you need to change a string, you simply will need to edit the translation file (xml) and "recompile" it with lrelease utility without building the application again.
There is a mechanism to dynamically translate texts in application, but it works a bit different than Android string resources, but achieves the same goals.
Qt uses i18n system modelled after standard, well known unix gettext. It works in a very similar way to iOS NSLocalizedString, if that rings a bell.
http://doc.qt.io/qt-5/qobject.html#tr
This is worth reading too:
http://en.wikipedia.org/wiki/Gettext
http://doc.qt.io/qt-5/internationalization.html
Android approach is a bit unique and you should not expect it to be a "standard everywhere". It works, it's ok, but it's not a standard way of doing things on desktop.
actually i'm thinking of creating a cool interface for my programming assignment , so i go around searching on how to do it so that such an effect can be create , below is the image .
The Question
1.)What is needed in order to create a program that run pseudographic(semigraphic or whatever they called it) that has menu like BIOS wizard did??I always see some program run in console but it could have graphical-like looking , for example blue environment , and user can use keyboard to choose a list of setting in a menu.
Thanks for spending time reading my question.
It's called Text-based user interface. There're several libraries for doing this. I think this is what you're looking for. :)
Cross platform, Interactive text-based interface with command completion
http://www.gnu.org/s/ncurses/
Ncurses(or maybe pdcurses) is probably what you need.
In the days of 16-bit Windows console windows used to support ANSI escape sequences (via the ansi.sys driver), but they no longer do.
For the apparent line graphics you need to use a platform specific solution anyway, so I recommend just writing an abstraction (functions, class) over the Windows APIs console functions.
The line graphics is done by using characters from the original IBM PC character set, codepage 437. At first you can just hardcode the various patterns. In order to make it seem more like line drawing to the code, or from the code's perspective, so to speak, you'll have to abstract things again. As I remember there is some partial but not complete system in the original codepage 437 character codes. But for Windows console you will need to use the Unicode character codes, which probably do not preserve the original system, so perhaps just define a map where these graphics characters are placed more systematically.
Possibly that already exists.
If you don't care about portability, the Windows API for this can be found here. It will supply all the functions you need, without the need to pack additional libraries with your application.
You can also look in to graphics.h, a non-standard Borland extension that a lot of older graphical games used to use. It goes far beyond the normal limits of the console, but is only supported by 16 bit systems, of which Microsoft has all but removed support for from Windows. You'd also need an ancient Borland compiler, or an emulation, though you probably want the original look and feel.
I like to print a document. The content of the document are tables and text with different colors. Does a lightwight printer-file-format exist, which can be used like a template?
PS, PDF, DOC files in my opinion are to heavy to parse. May there exist some XML or YAML file format which supports:
Easy creation (maybe with a WYSIWYG-Editor)
Parsing and manipulation with Library-Support
Easy sending to the printer (maybe with Library-Support)
Or do I have to do it the usual way and paint within a CDC?
I noticed you’re using MFC (so, Windows). In that case the answer is a qualified yes. In recent versions of Windows, Microsoft offers the XPS Document API which lets you create and manipulate a PDF-like document using XML, which can then be printed using the XPS Print API.
(For earlier versions of Windows that don’t support this API, you could try to deal with the XPS file format directly, but that is probably a lot harder than using CDC. Even with the API you will be working at a fairly low level.)
End users can generate XPS documents using the XPS print driver that is available for free from Microsoft (and bundled with certain MS products—they probably already have it on their system).
There is no universal language that is supported across all (or even many) printers. While PCL and PS are the most used, there are also printers which only work with specific printer drivers because they only support a proprietary data format (often pre-rendered on the client).
However, you could use XSL-FO to create documents which can then be rendered to a printer driver using library support.
I think something like TeX or LaTeX (or even troff or groff) may meet your needs. Google them and see.
There are also libraries to render documents for print from HTML source. Look at http://libharu.sourceforge.net/ for example. This outputs a printer-ready .PDF
A think that Post Script is a really good choice for that.
It is actually a very simple language, and it must be very easy to parse becuse it is stack-oriented. Then -- most printers supprort it, and even if you have no support you can use GhostScript to convert for many different formats (Consider GS as a "virtual PS supporting printer").
Finally there are a lot of books and tutorials for the language.
About the parsing -- you can actually define new variables and functions in PS. So, maybe, your problem can be solved (almost) entirely using PS.
HTML + CSS can be printed -- properly. CSS was designed to support this with the media attribute to specify that your CSS is for printer layout, not for screen layout. Tools like PRINCE (free + commercial versions) exist to render this for printing.
I think postscript is the markup language used by printers. I read this somewhere, so correct me if postscript is now outdated.
http://en.wikipedia.org/wiki/PostScript
For more powerful suite you can use Latex. It will give options of creating templates where you can just copy the text.
On a more GUI friendly note, MS-Word and other word processors have templates. The issue is they are not of a common standard or markup.
You can also use HTML to render stuff in a common markup but it will not be very printer friendly.
I would like to parse the menu structure for Gnome Panels (the standard Gnome Desktop application launcher) and it's KDE equivalent using c/c++ function calls. That is, I'd like a list of what the base menu categories and submenu are installed in a given machine. I would like to do with using fairly simple c/c++ function calls (with NO shelling out please).
I understand that these menus are in the standard xdg format.
I understand that this menu structure is stored in xml files such as:
/home/user/.config/menus/applications.menu
I've looked here: http://www.freedesktop.org/wiki/Specifications/menu-spec?action=show&redirect=Standards%2Fmenu-spec but all they offer is the standard and some shell files to insert item entries (I don't want shell scripts, I don't want installation, I definitely don't want to create a c-library from the XDG specification. I want to find the existing menu structure). I've looked here: http://library.gnome.org/admin/system-admin-guide/stable/menustructure-13.html.en for more notes on these structures. None of this gives me a good idea of how determine the menu structures using a c/c++ program.
The actual gnome menu structures seem to be a horrifically hairy things - they don't seem to show the menu structure but to give an XML-coded description of all the changes that the menus have gone through since installation. I assume gnome panels parses these file so there's a function buried somewhere to do this but I've yet to find where that function is after scanning library.gnome.org for a couple of days. I've scanned the Nautilus source code as well but Panels seem to exist elsewhere or are burried well.
Thanks in advance
After much painful research... it seems the most stable approach is to take the gnome menu parsing code, rip it of the tar ball and use it locally.
The version I used is here:
http://download.gnome.org/sources/gnome-menus/2.28/gnome-menus-2.28.0.1.tar.gz
This code loudly proclaims that it shouldn't treated as any kind of API so one is forced to, as I said rip it of the gnome tree and keep a local copy for one's own application (gather than dynamically linking to a library).
The KDE version of the menu-parsing code seems like it could be used more transportably but actually depends heavily on KDE's virtual file system. As far as I can tell, the code gnome works stand-alone. The test-file can serve as a template for doing your own parsing.