Tag: winapi

Entries for tag "winapi", ordered from most recent. Entry count: 18.

Uwaga! Informacje na tej stronie mają ponad 5 lat. Nadal je udostępniam, ale prawdopodobnie nie odzwierciedlają one mojej aktualnej wiedzy ani przekonań.

Pages: > 1 2 3 >

# Generating and Compressing AVI Video Files

18:31
Mon
28
Dec 2009

Yesterday I've decided to share all my home code using Project Hosting on Google Code, so now everyone can browse my code online by entering project called blueway. I'll be very glad to hear your opinions and suggestions about it.

Today I've researched subject of generating video data as AVI file, compressed on the fly with codecs installed in Windows. After succeeding with that I've created simple class to support this task, called VideoCompressor. You can find it in Video.hpp and Video.cpp. Test code is in ProgramMain.cpp, line 2318. It generates a 5 second video with a white horizonal line moving from bottom to top.

Here are some technical details. Functionality needed to handle video files is already inside Windows API, described in MSDN Library. The AVIFile library contains functions like AVIFileOpen, AVIFileCreateStream, AVIStreamWrite. It supports reading and writing AVI files. You need to include <Vfw.h> header and link with Vfw32.lib file. AVI is actually a container file format made of RIFF data chunks identified by 4-byte FOURCC codes (if you ever loaded 3DS models, you know what I mean). It can contain multiple streams like video and audio, which can be coded in many different formats, compressed and decompressed by codecs.

Compressing and decompressing frames of video with installed codecs can be done with Video Compression Manager library. You can display standard, system dialog window to let the user choose and configure codec with ICCompressorChoose function. Then you can just pass subsequent video frames as uncompressed RGB images to a function like ICSeqCompressFrame and you get a piece of compressed data that you can save to your AVI file.

Comments | #video #winapi Share

# Redirecting Standard I/O to Windows Console

20:10
Sat
28
Nov 2009

Every process, no matter if under Windows or Linux, has standard text streams called input, output and error. Of course it makes most sense when you deal with command line applications, where you can directly interact with it using these streams. If you use Linux, you are probably familiar with redirecting streams to file using > operator or to another application using | operator. We use these streams in C++ code with standard C library (like printf and scanf functions) or standard C++ library (like std::cout and std::cin streams). But what if we write a GUI application in Windows (like a game), which has WinMain instead of main entry point and thus doesn't have console?

There is a simple WinAPI function called AllocConsole, which opens this black system console for your Win32 application. But today I've noticed that the console opened this way doesn't handle standard I/O! I've tried to do std::cout << "Hello World" and nothing happened. So after some googling I've found a hacky solution (or maybe rather a smart code snippet? :) in an article hosted at Andrew Tucker's Home Page, published in 1997 in Windows Developer Journal: Adding Console I/O to a Win32 GUI App. Here is my version of this code with all necessary includes:

#include <windows.h>
#include <ios>
#include <cstdio>
#include <io.h>
#include <fcntl.h>

void RedirectStandardIo()
{
  /* This clever code have been found at:
  Adding Console I/O to a Win32 GUI App
  Windows Developer Journal, December 1997
  http://dslweb.nwnexus.com/~ast/dload/guicon.htm
  Andrew Tucker's Home Page */

  // redirect unbuffered STDOUT to the console
  long lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE);
  int hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
  FILE *fp = _fdopen(hConHandle, "w");
  *stdout = *fp;
  setvbuf(stdout, NULL, _IONBF, 0);

  // redirect unbuffered STDIN to the console
  lStdHandle = (long)GetStdHandle(STD_INPUT_HANDLE);
  hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
  fp = _fdopen( hConHandle, "r" );
  *stdin = *fp;
  setvbuf(stdin, NULL, _IONBF, 0);

  // redirect unbuffered STDERR to the console
  lStdHandle = (long)GetStdHandle(STD_ERROR_HANDLE);
  hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
  fp = _fdopen( hConHandle, "w" );
  *stderr = *fp;
  setvbuf(stderr, NULL, _IONBF, 0);

  // make cout, wcout, cin, wcin, wcerr, cerr, wclog and clog point to console as well
  std::ios::sync_with_stdio();
}

Comments | #winapi Share

# Executable File Path

17:18
Sat
14
Nov 2009

There have been a question recently at our forum about how to get the full path of the current executable file.

First idea proposed was to use argv[0] argument from main function, but this solution is wrong. The proof is a simple example with my program called Parametrizer. As this screenshot shows, program run from the command line with current directory equal to the directory where the executable file lies results in the argv[0] being set to only file name, without the full path.

The correct solution for Windows is to use GetModuleFileName function, just like this:

char exePath[MAX_PATH];
GetModuleFileName(NULL, exePath, _countof(exePath));

Then you can extract only the directory path and append any other file name to be sure you always access files installed with your application from the correct directory refered by the full, absolute path. I'll write more about function for path string processing and the concept of current directory soon...

Comments | #c++ #winapi Share

# Dialog Layout Manager in MFC

21:08
Sat
08
Aug 2009

Sometimes I write some tools using C++ and MFC. In the Linux world it is common that GUI windows are resizeable. In Windows its not the case, but sometimes it would be nice to be able to resize a dialog window to see more information, like more rows and colums in a list. After repositioning and resizing controls in a window with my custom code I've decided to automate this task.

There are many possible approaches to this problem. WinAPI (and thus MFC) does not provide by itself any solution to automatically align controls inside a resizeable window. Each control has just its fixed rectangle (left, top, width, height) inside parent window. Delphi VCL uses Align property to snap selected controls (like Panel containing child controls) to left, right, top or bottom edge of the window. Qt encourages to design all windows with Layouts. For example, Vertical Layout splits the window into rows and automatically adjusts controls inside, one under the other.

But the solution of my choice is the one based on .NET. Controls in Windows Forms have a property called Anchor so they can be anchored to any of four possible window edges: left, top, right and bottom. If a controls is anchored only to left and top edges, it just doesn't change its position or size. If the control is anchored to right and bottom edges (for example: a button), it changes its position as window is resized so it preserves its distance to right and bottom edge of the window. If the control is anchored to all four possible window edges, it is resized to preserve distance to all window edges same as designed (for example: a list occupying central part of the window).

I've written a class which I called DialogLayoutManager. It's very easy to use and automates control resizing and repositioning inside an MFC window. All you need to do at the beginning is to create an object of this class, register your controls with selected anchors and call Save method:

m_LayoutManager->SetControl(GetDlgItem(ID_BTN_CANCEL),
  DialogLayoutManager::ANCHOR_RIGHT | DialogLayoutManager::ANCHOR_BOTTOM);
m_LayoutManager->SetControl(GetDlgItem(ID_BTN_OK),
  DialogLayoutManager::ANCHOR_RIGHT | DialogLayoutManager::ANCHOR_BOTTOM);
m_LayoutManager->Save(this);

Layout manager remembers positions and sizes of registered controls together with starting window size. Now all you need to do when the window is resized is to call Restore method. Layout manager will adjust registered controls according to new window size and specified anchors. For example, two buttons showed above will stay in bottom-right corner of the window.

void CDialog01::OnSize(UINT nType, int cx, int cy)
{
  ...
  if (LayoutManager && LayoutManager->IsSaved())
    m_LayoutManager->Restore(this);
}

Here is the code of my DialogLayoutManager class and usage example: DialogLayoutManager.cpp. It's easy to translate this code to pure WinAPI.

Comments | #gui #mfc #winapi Share

# Efficient Finding of Duplicated Files

21:06
Tue
14
Jul 2009

I've recently wrote a tool for finding duplicated files in a given directory. I wanted to do it efficiently and here is my algoritm.

My basic idea is to first recursively enumerate all files in the directory and its subdirectories and sort their descriptions by file size. Making it this way, we can then iterate through this list and for each file look ahead to see how many other files have same size. If two files have different sizes, they are obviously not equal in terms of their content. So if there is only one file with particular size, it can just be skipped. If there are two files with same size, we must just compare them by content.

If there are many files with same size, things become more complicated, as any possible combinations of them can turn out to be identical. My solution is to compare two files by a "header" (lets say - first 1024 bytes) and if they are equal - by MD5 checksum of their whole content. Checksum of each file is lazy evaluated, so it's calculated only once, the first time its needed.

As I iterate through the sorted file list, I mark reported files not to process them again. I can do it because I ensure that if a file is reported, all other identical files are also already reported. In my real code I do the same with files I encounter errors with, but here I wanted to simplify the code.

Read full entry > | Comments | #algorithms #winapi Share

# MFC i Smart PropertyGrid

16:43
Sat
06
Jun 2009

Używam w pracy MFC i powiem wam, że wbrew temu co się mówi (i co wcześniej powtarzałem za innymi), to wcale nie jest taka zła biblioteka. Ta dostępna w płatnych wersjach Visual C++ biblioteka do GUI to tak naprawdę cienka, obiektowa nakładka na WinAPI. Tak więc ma swoje klasy odpowiadające m.in. różnym kontrolkom interfejsu, obiektom GDI itp., ale z zestawów flag bitowych czy też zasobów z zaprojektowanymi graficznie okienkami korzysta już z tych samych, co czyste WinAPI. Nie oferuje zbyt wiele ponad to, co API systemowe, ale trochę uprzyjemnia pracę. Jeśli ktoś zna dobrze WinAPI, to nie ma kłopotów z opanowaniem MFC ani powodów do narzekań, chyba że co najwyżej na to, że biblioteka jest tym czym jest i niczym więcej.

Szukałem wczoraj rozwiązania kwestii kontrolki Property Grid dla MFC i znalazłem bibliotekę Smart PropertyGrid.MFC firmy Visualhint. Jest świetna - ładna, potężna, rozszerzalna, a dzięki dobrze zaprojektowanemu interfejsowi opartemu na wielu klasach i koncepcji iteratorów, także wygodna w użyciu. Twórcy udostępnili ją całkowicie za darmo, bo teraz rozwijają i sprzedają wersję tej kontrolki dla .NET (choć przecież platforma .NET ma taką kontrolkę w standardzie).

Smart PropertyGrid.MFC

Comments | #c++ #gui #libraries #winapi #visual studio Share

# Pliki INI w WinAPI

00:04
Tue
03
Feb 2009

Stare dobre pliki INI to format tekstowy do przechowywania konfiguracji. Na przykład:

[Display]
Width=1280
Height=800
FullScreen=true

Czasami ten format może się przydać, a chociaż nie jest skomplikowany, to nie każdy ma ochotę pisać do niego własny parser. Dlatego warto wiedzieć, że WinAPI zawiera proste i wygodne funkcje do obsługi plików INI. Znajdują się na dole listy Registry Functions. Można się domyślać, że z każdym wywołaniem plik jest od nowa otwierany i wczytywany, więc te funkcje nie grzeszą szybkością, ale do prostych zastosowań będą OK. Na przykład wczytanie wartości:

char Buf[256];
GetPrivateProfileString(
  "Display", // Nazwa sekcji
  "FullScreen", // Nazwa klucza
  "false", // Wartość domyślna
  Buf, _countof(Buf), // Bufor wyjściowy
  FileName); // Nazwa pliku INI ze ścieżką

Comments | #winapi Share

# Crash Dump

21:13
Fri
03
Oct 2008

Życie programu w Windows nie kończy się wraz z błędem ochrony pamięci albo dzieleniem przez zero. Takie błędy można łapać, a co więcej, można z nich tworzyć tzw. Crash Dump - plik DMP, który wysłany do programisty może mu pomóc zlokalizować problem.

Należy objąć swój kod w sekcję __try { ... } __except ( MojaFunkcja( GetExceptionInformation() ) ) { }, a w swojej funkcji wywołać MiniDumpWriteDump pochodzącą z biblioteki Dbghelp. Ta biblioteka z kolei rozprowadzana jest jako Debugging Tools for Windows, ale do użycia tej funkcji wystarczy wersja domyślna z Windows XP.

Potem plik DMP można otworzyć w Visual C++ (rozszerzenie jest z nim domyślnie skojarzone). Trzeba jeszcze posiadać plik PDB z symbolami (powstaje w czasie kompilacji obok EXE/DLL) i już można zobaczyć gdzie wystąpił błąd, analizując np. stos wywołań Call Stack. Można nawet ściągnąć symbole do bibliotek systemowych. Ścieżki do symboli ustawia się w Tools > Options > Debugging > Symbols, lokalizacja z symbolami od bibliotek systemowych to http://msdl.microsoft.com/download/symbols.

Niestety sprawa nie jest taka prosta. Dodatkowo można na przykład postawić tzw. "Symbol Server" (to po prostu specjalny katalog zarządzany przez dedykowane programy z pakietu Debugging Tools for Windows), a podczas używania tych mechanizmów pojawia się wiele problemów (może ktoś coś poradzi na mój problem? :)

Comments | #c++ #winapi Share

Pages: > 1 2 3 >

STAT NO AD
[Stat] [STAT NO AD] [Download] [Dropbox] [pub] [Mirror] [Privacy policy]
Copyright © 2004-2018