Кодерский уголок

Andreus778, никогда так не делай:

 

Borland C++ 3.1

---------- Сообщение добавлено в 13:39 ---------- Предыдущее сообщение размещено в 13:36 ----------

Я так и не делаю. Создал папку "ALLEGRO" и в неё скинул все файлы allegro 1.02. Как директории прописывать не пойму. Например, там "C:\BORLANDC\INCLUDE". Как мне прописать ещё одну директорию к "C:\BORLANDC\ALLEGRO"?

 

Такое окно должно быть:

 

Прописал. При комплияции нет Варнингов и Ерроров, но когда кликаю Build All или Run, то вылезают 4 такие ошибки.

 

В настройках проекта надо указать либы в которых есть эти функции.

 

Как дойти до настроек проекта?

 

А хрен его знает. Судя по твоему скрину - в пункте меню Project. Там что-нить типа Linker settings или Link libraries.
Ты пойми принцип:
Есть компилятор, он преобразует имеющийся исходный код в объектные файлы. В include есть h файлы, в них, грубо говоря, список функций, про которые компилятор должен думать, что они есть.
Есть линковщик, он соединяет все объектные файлы в один исполняемый или библиотеку. При этом он проверяет, а где, собсна, двочиный код всех использующихся функций? Если это твой код - всё ок, если это Аллегра - ты должен указать линковщику где искать эти функции, т.е. путь к либам и сами файлы библиотек.
Надо чётко понимать разницу между ошибками компилятора и ошибками линковщика.

 

Короче, сменил компилятор на Ваткомовский. (DOSBox юзаю). Та же проблема, но на этот раз заголовочный скинул в C:\WATCOM\H. Эти долбаные андефайнед...
Он же находит ALLEGRO.H, вернее не ругается, что его нету.



Я понял, что ругается Линкер, а не Компилятор. Как быть с этим Линкером?

 

Нужно указывать не только хидеры, но и либы.
Да вот вроде выше сказали.

 

Либы это файлы .LIB? Но тут такого дела нету.



---------- Сообщение добавлено в 21:36 ---------- Предыдущее сообщение размещено в 21:23 ----------

А как пути к либам прописать в батнике? Просто покажу туда же(C:\WATCOM\ALLEGRO).

 

Скомпилируй библиотеку из исходников. Какие именно файлы нужны для этого посмотри в readme.txt.

 

В Delphi есть функция проверки запущенного приложения чтобы не дать ему запуститься поверх себя. Скрипт перед запуском формы:
var result :integer;
-----------------
result:=FindWindow('TForm1',pchar(Application.Title));
if result<>0 then begin
Application.MessageBox('Программа уже загружена',
pchar(Application.Title),mb_iconwarning);
Halt(1);
Но я уже с морально устаревшим Delphi больше не работаю, уже перешел на C# и к сожалению я там не нашел функции типа "FindWindow". Можно сделать и в С# чтобы программа не смогла сама себя запустить и чтобы программу нельзя было запустить при её наличии в работе

 

Лучше всего будет сразу настроить переменные окружения:

Код:

 - INCLUDE  - points to directories containing header files used by the
              C/C++ compilers
 - LIB      - points to directories containing library files; note that
              Open Watcom linker is able to locate Open Watcom runtime
              libraries without this variable

(readme.txt)

---------- Сообщение добавлено в 02:24 ---------- Предыдущее сообщение размещено в 02:21 ----------

Код:

        [DllImport("USER32.DLL", CharSet = CharSet.Unicode)]
        public static extern IntPtr FindWindow(string lpClassName,
            string lpWindowName);

Вот как-то так. Как и с остальными функциями WinAPI.

 

Эти СССАБАКИ разработчики Visual Studio C# сделали так что переменные присвоены в Program.cs после запуска приложения Application.Run() и при запуске процедуры private void Form1_Load(object sender, EventArgs e) все удаляются и параметры с которой запускалась программа удаляются полностью. Параметры считывались в static void Main(string[] args) и они хранятся до тех пор пока форма не запустится, а при запуске формы УДАЛЯЮТСЯ БЕЗВОЗВРАТНО. Программируя в C# выходит нельзя сделать так что программа "образец.exe -параметр" содержала в форме label1.text = (тот самый параметр). В морально устаревшем Delphi это можно было сделать, а вот в C# это сделать НЕЛЬЗЯ ПОЛНОСТЬЮ И НИКОГДА. Как обратиться к разработчикам C# чтобы разрешили сохранение параметров запущенной программы во время запуска и появления формы?

 

Прикинь, ты можешь передать нужные данные куда надо из main, когда создаёшь главную форму. Ох уж эти биллгейтсы - лишь бы жизнь испортить, то ли дело линупс!!!

Проклятый MSDN подло содержит в себе ответы на все вопросы - http://social.msdn.microsoft.com/Fo...instance-application-in-c?forum=csharpgeneral

Ребята, вы ездили на автомобиле с навигатором? Гораздо легче, но маршрут запоминаешь в несколько раз медленнее, чем один раз, но самостоятельно разобраться с картой и названиями улиц. Намёк понятен? Вы задаёте вопросы, ответы на которые есть в интернете. Более того, они есть на всех языках и не на одном каком-то скрытом сайте, потому что вопросы ваши - базовые, начального уровня, всё это обсосано миллион раз. И главное, почти всё это описано в документации к вашим инструментам.

 

Offtop

42!

Абсолютно согласен, Гугл выдает тонны инфы по подобным запросам.

И чтобы не оффтопить, вопрос, на который Гугл не дал прямого ответа. Есть 16-битная винда. Реальный режим (да-да, вы уже догадались, что я про Win 2.x). Задача: нужно прочитать файл размером более 64К. Казалось бы, что может быть проще, делаешь GlobalAlloc GlobalLock и читаешь. Но! Штатная функция read, которая так хорошо работала с LocalAlloc намертво вешает всею винду. Причем винда виснет даже при пробе прочитать 1 байт. Приходится выделять буфер, в который читаю через read, а потом в цикле кидаю в память из GlobalAlloc. Че за нафиг-то такой?

 

Zelya, не очень понял в чём именно проблема, ну создаёшь несколько буферов по 64K. Если юзать himem.sys, то вроде можно было большой буфер создавать. В DOS, в древней винде не работал.

 

Zelya, а если перед этим вызвать GlobalCompact? Хотя это, конечно, пальцем в небо. Я с двойкой тоже не знаком

 

Если я не ошибаюсь, то для создание нескольких буферовпо 64К нужно использовать тот же GlobalAlloc, что не решает проблему.

himem.sys, можно мспользовать как "фичу", но программа должна уметь работать и без него.

Попробовал, не помогает. Хотя есть кое-какие соображения. В зависимости от количества загружаемых байтов, винда может зависнуть сразу, а может еще попытаться, например, выполнить следующую операцию по обновлению окна или плюнуть диалог с непонятной ошибкой (просто набор ASCII символов). Сдается мне, что read, каким-то образом игнорирует сегментацию и гадит в данные программы, нарушая ее работу и всей системы в целом (многозадачность-то кооперативная).

 

Записав данные фиг знает куда программа может сразу кони двинуть, а может и потом. Это от везения зависит (когда сразу - гораздо лучше). Ваще поведение, что ты описываешь - это тупо запись в невыделенную область памяти. В базовой памяти ты никак не можешь выделить память больше 64K на один указатель. Хотя можно, наверное, поиграться с сегментами.
Кстати, что за данные ты пытаешься загрузить, может нет смысла грузить целиком?