Заголовки Windows, Ada Опции

[TarasBer]

Я поставил пакет win32ada, он создал папку include\win32ada
Если написать первой строкой test.gpr with "win32ada", то среда ругается при открытии пакета:

[2011-02-08 16:25:57] C:\Program Files\ADA\projects\TEST\test.gpr:1:06: unknown project file: "win32ada"
[2011-02-08 16:25:57] Error while loading project 'C:\Program Files\ADA\projects\TEST\test.gpr'. Loading the default project.

Ну я это убрал.
Добавил в test.gpr строчку

for Source_Dirs use ("..\..\include\win32ada\**");

Пишу в test.adb with win32.winuser (вроде все основные функции, типа окно нарисовать итд, там).
Компилирую.

gnatlink "C:\Program Files\ADA\projects\TEST\test.ali" -shared-libgcc -g -g -fprofile-generate -o "C:\Program Files\ADA\projects\TEST\test.exe"
c:/program files/ada/bin/../libexec/gcc/i686-pc-mingw32/4.3.6/ld.exe: cannot find -lwin32ada
collect2: ld returned 1 exit status
gnatlink: error when calling C:\Program Files\ADA\bin\gcc.exe
gnatmake: *** link failed.

[2011-02-08 16:28:19] process exited with status 4 (elapsed time: 06.26s)

Что делать?

[volvo]

в каком модуле описаны константы wmsz_TopLeft итд?

Не описаны они вообще. Кому надо - тот открывает MSDN -> WM_SIZING Message, смотрит там на значения констант, и пишет себе в пакет:

WMSZ_TOPLEFT : constant := 4;
WMSZ_TOPRIGHT : constant := 5;
--  и так далее ...

Вообще взаимодействие с виндой сделано очень неудобно, на каждый чих свой тип, всех их надо приводить, а то и конвертировать

Взаимодействие сделано в стиле языка. То, что в WinAPI куча дублирующих друг друга типов - это только проблемы WinAPI. Ада не может позволить программисту взять тип Integer, и использовать его как HBRUSH. Потому, что это сегодня они совпадают по размеру. А завтра (с выходом новой версии Windows или нового сервис-пака) могут и перестать совпадать. Именно поэтому, кстати, в свое время перестали работать многие программы при переходе Win16 -> Win32. А пользовались бы правильными типами (а не уверенностью в том, что размер одного будет вечно совпадать с размером другого) - работало бы до сих пор, достаточно было бы просто перекомпилировать код.

на каждый чих компилятора долго подбирать какой тип в какой надо преобразовать, чтобы это скомпилировалось, кошмар.

Ничего не надо подбирать. Достаточно посмотреть на тип переменной-приемника, и привести тип переменной-источника (или выражения) к нему.

Да ещё и куча функций, требующих параметр по ссылке, а давать ссылку на локальную переменную нельзя, приходится портить код и заводить глобальные переменные для того, чтобы применить их в локальной процедуре и передать ссылку на них, либо заводить указатель и выделять память при входе в процедуру, короче, одни костыли кругом.

Пример костылей можно посмотреть? Что-то я особых костылей, связанных с необходимостью передать по ссылке второй параметр BeginPaint, не вижу:

   function Window_Proc (hwnd    : Win32.Windef.HWND;
                         message : Win32.UINT;
                         wParam  : Win32.WPARAM;
                         lParam  : Win32.LPARAM) return Win32.LRESULT is

      use Interfaces.C;
      -- ...
      My_DC : Win32.Windef.HDC;
      bResult : Win32.BOOL;
      Paint_Record : aliased Win32.Winuser.PAINTSTRUCT;

   begin

      case message is

         --  ...

         when Win32.Winuser.WM_PAINT =>
            My_DC := Win32.Winuser.BeginPaint (hwnd, Paint_Record'Access);

            -- ... Рисуем на My_DC ...

            bResult := Win32.Winuser.EndPaint (hwnd, Paint_Record'Access);

         when others => return
           Win32.Winuser.DefWindowProc (hwnd, message, wParam, lParam);

      end case;
      return 0;

   end Window_Proc;

(пример из совершенно рабочей программы, валялся у меня на флешке). Что я не так делаю?