Jak używać procedur z Unit2 w Unit1 w Delphi?

0

Stworzyłem formę najpierw, tam dałem button i pole Edit. Następnie dodałem Unit2 i w Unit2 wpisałem tak:

 

unit Unit2;

interface

implementation

uses Unit1;

procedure Wczytaj;
begin
  IniFile.Create('c:\u.ini');
  Form1.Edit1.Text:= IniFile.ReadString('Sekcja1', 'pole', 'brak');

  IniFile.Free;
end;

end.

no i jak teraz w Form1 (w Unit1) w OnCreate Formy użyć procedury Wczytaj? Co muszę dodać na górze kodu? Dodałem na formie1 w uses Unit2, ale nadal wywala błąd przy procedurze Wczytaj. Po prostu wolałbym trzymać część procedur w Unit2, bo w Unit1 mam tyle kodu naklepanego, że śmietnik się robi, a tak to wtrącę procedury do zapisu, odczytu INI i kilka innych w Unit2 i będzie czytelniej

0
nowe napisał(a):

Po prostu wolałbym trzymać część procedur w Unit2, bo w Unit1 mam tyle kodu naklepanego, że śmietnik się robi, a tak to wtrącę procedury do zapisu, odczytu INI i kilka innych w Unit2 i będzie czytelniej

To ja już reszty kodu wolę nie widzieć ... Proponuję nie pozostawiać domyślnych nazw modułów,form itd. bo "Unit1,Unit2" czy "Form1,Form2" do najczytelniejszych nie należy. Żebyś mógł użyć w Unit1 procedurę Wczytaj z Unit2, dodaj tą procedurę do public - jak przypuszam - Form2, czyli :

type
  TForm2 = class(TForm)
  private
    { Private declarations }
  public
    procedure Wczytaj;
  end;

...

procedure TForm2.Wczytaj;
var

....

Edit : Aj sorki, nie zauważyłem, że moduł nie zawiera klasy Formy, chyba że nie jest to pełny kod, więc jeśli nie masz TForm w module wystarczy, że zrobisz tak :

unit Unit2;
 
interface
 
   procedure Wczytaj;

implementation
 
uses Unit1;
 
procedure Wczytaj;
begin
  IniFile.Create('c:\u.ini');
  Form1.Edit1.Text:= IniFile.ReadString('Sekcja1', 'pole', 'brak');
 
  IniFile.Free;
end;
 
end.
0

druga część pomogła. Wprowadziłem tylko zmiany, bo z pośpiechu wtedy źle IniFile Create zrobiłem i nie dodałem IniFiles

unit Unit2;

interface
  procedure Wczytaj;

implementation

uses Unit1, IniFiles;

procedure Wczytaj;
begin
  IniFile:= TIniFile.Create('c:\u.ini');
  Form1.Edit1.Text:= IniFile.ReadString('Sekcja1', 'pole', 'brak');
  IniFile.Free;
end;

end.

śmiga.
Dziękuję bardzo za pomoc :)
To teraz lecę w starym programie dodawać różne funkcje w Unit2

0

Życzę powodzenia z ewentualnym zapisem do takiej lokalizacji pliku ini w przypadku gdy user ma właczone UAC i nie odpali Twojego programu na prawach admina. Ja też jestem za plikami ini niż za zaśmiecaniem rejestru, jeżeli nie jest to konieczne. Jednak pliki konfiguracyjne najlepiej przechowywać w %APPDATA%%%%%%\PODKATALOG_PROGRAMU. Pogoogluj sobie jak w Delphi ustalić ścieżke do takich podkatalogów systemowych oraz jak tworzyć podkatalogi, które nie istnieją w danej ścieżce.

0
olesio napisał(a):

Życzę powodzenia z ewentualnym zapisem do takiej lokalizacji pliku ini w przypadku gdy user ma właczone UAC i nie odpali Twojego programu na prawach admina. Ja też jestem za plikami ini niż za zaśmiecaniem rejestru, jeżeli nie jest to konieczne. Jednak pliki konfiguracyjne najlepiej przechowywać w %APPDATA%%%%%%\PODKATALOG_PROGRAMU. Pogoogluj sobie jak w Delphi ustalić ścieżke do takich podkatalogów systemowych oraz jak tworzyć podkatalogi, które nie istnieją w danej ścieżce.

Ja mam UAC wyłączony w win7 całkiem więc nie testowałem nigdy tego.
Domyślnie zapisuję ini do katalogu z programem w folderze ustawienia.

  1. Ale mówisz, że jak ktoś na pulpicie będzie trzymał folder z programem, to wtedy pliki INI w ogóle się nie utworzą? :( Jeśli tak to tragedia.
  2. A jeśli użytkownik odpali program klikając prawym -> uruchom jako administrator, wtedy pliki INI utworzy?
  3. A jeśli wrzucę program razem z plikami INI, gość sobie wypakuje program, uruchomi go z dysku C, to wtedy pliki INI program odczyta? I zapisze zmiany w plikach INI, czy w ogóle pomimo istnienia plików INI, windows i tak zabierze prawa do zapisu?

A co do katalogu %APPDATA%, wolałbym uniknąć tego. Wolę by ktoś kasując folder z programem (program i tak jest portable), wywalił i program i wszystkie pliki od razu (w tym INI). Instalatora nie chcę robić, bo sam osobiście nie lubię programów, które mają instalatory, choć im taki instalator bardzo często jest zbędny.

0
nowe napisał(a):

Ja mam UAC wyłączony w win7 całkiem więc nie testowałem nigdy tego.
Domyślnie zapisuję ini do katalogu z programem w folderze ustawienia.

Ja również mam wyłączony UAC, bo mnie wkurza, ale trzeba myśleć globalnie jeżeli tego programu ma używac ktoś poza Toba. Poza tym śmiecenie akurat w C:\ to też zły pomysł.

  1. Ale mówisz, że jak ktoś na pulpicie będzie trzymał folder z programem, to wtedy pliki INI w ogóle się nie utworzą? :( Jeśli tak to tragedia.

Tylko lame ne0 kidsy sciągają programy zawsze na pulpit, tacy pr0 l4my jak ja używają Total Commandera i nim się wspierają przy operacjach na pobranych plikach. Poza tym programy raczej warto trzymać w Program Files, a więc przyda się instalator i ewentualne dodanie odpowiedniego manifestu do zasobów programu aby wymusić jego uruchomienie jako Admin.

  1. A jeśli użytkownik odpali program klikając prawym -> uruchom jako administrator, wtedy pliki INI utworzy?

Wtedy powinien, a najlepiej zamiast pytać po prostu włacz na jakiś czas UAC i zrób testy.

  1. A jeśli wrzucę program razem z plikami INI, gość sobie wypakuje program, uruchomi go z dysku C, to wtedy pliki INI program odczyta? I zapisze zmiany w plikach INI, czy w ogóle pomimo istnienia plików INI, windows i tak zabierze prawa do zapisu?

Z właczonym UAC o ile się orientuje do zapisu plików poza paroma lokalizacjami musiz mieć prawa do tego. Najlepiej zamiast pytać mnie, to zrób porządne testy przed wypuszczeniem swojego programu.

A co do katalogu %APPDATA%, wolałbym uniknąć tego. Wolę by ktoś kasując folder z programem (program i tak jest portable), wywalił i program i wszystkie pliki od razu (w tym INI). Instalatora nie chcę robić, bo sam osobiście nie lubię programów, które mają instalatory, choć im taki instalator bardzo często jest zbędny.

Jak instalator Ci zbędny to informuj użytkownika lub zrób batcha albo przycisk w programie do czyszczenia pliku z konfiguracją i ewentualnego podfolderu. W dzisiejszych czasach wszystkie programy, które nie korzystają z samego exeka i configu w typowej do spradzenia ścieżce powinny mieć instalatory jeżeli chcemy ułatwiać potencjalnym użytwkikom życie i chcemy aby w momencie jak chcą się pozbyć naszego programu z dysku nie posiadali na nim dodatkowych śmieci na dysku czy w rejestrze. Także zaintersuj się NSISem lub InnoSetup. Są najpopularniejsze. Ja mimo iż umiem programować tylko w Delphi / Pascalu, to jako pierwszym zainteresowałem się NSISem do robienia prostych instalek na własne potrzeby. Podejrzewam jednak, że i do jednego i do drugiega znajdzie się w google wiele dokumentacji i przykładów. Tak na pewno jest w przypadku NSISa. Do Inno Setup nie szukałem specjalnie, bo nie go używam póki co.

0

@olesio
aha, dzięki za informacje

olesio napisał(a):

Poza tym śmiecenie akurat w C:\ to też zły pomysł.

Tylko lame ne0 kidsy sciągają programy zawsze na pulpit. Poza tym programy raczej warto trzymać w Program Files, a więc przyda się instalator i ewentualne dodanie odpowiedniego manifestu do zasobów programu aby wymusić jego uruchomienie jako Admin.

Jakie śmiecenie na C? Przecież wyraźnie napisałem, że pliki INI trzymam w katalogu z programem w stylu katalog_glowny_programu\pliki\ustawienia.ini więc to nie jest żadne śmiecenie.
ExtractFilePath(Application.ExeName) + 'pliki\ustawienia.ini'

Dlaczego uważasz, że tylko lamerzy pobierają programy na pulpit? Sam używam czasem niektórych programów z pulpitu, bo takie programy mają tylko jeden plik EXE, zero plików konfiguracyjnych. Np. jeden program do wywalania EXIF z plików graficznych, inny do bezpowrotnego kasowania plików i jeszcze dwa inne programy. Żaden z tych programów poza plikiem exe, nie ma ani jednego innego pliku także wg ciebie jestem lamą? Bzdura i tyle.

0

Wczułeś się niepotrzebnie. Przecież żartowałem. Każdy robi jak uważa. Tylko mnie nieraz śmieszy fakt, że ludzie nadmiernie zaśmiecają sobie pulpit, jak można ładniej zrobic katalog do którego pobieramy pliki i do niego trzymać skrót na pulpicie. Chociaż sam wiem, że nektórzy jakby boją się Total Commandera wręcz jak diabeł święconej wody. Ale w przypadku mojego leciwego ojca jest to nawet zrozumiałe, że nie chce mu się bawić w coś nieznanego. Ale młodzi ludzie i zwłaszcza programiści nawet amatorzy powinni wedlug mnie sobie ułatwiać życie róznymi narzędziami.

0

znalazłem gdyby ktoś chciał ścieżkę do np. APPDATA w stylu:
C:\Users\NazwaUżytkownika\AppData\Roaming

Edit1.Text := GetEnvironmentVariable('APPDATA');

więcej info na:
http://docwiki.embarcadero.com/Libraries/en/System.SysUtils.GetEnvironmentVariable

Nie sprawdzałem z UAC, ale UAC powinien pozwolić tworzyć tam folder + plik INI?

0

Ja również mam wyłączony UAC, bo mnie wkurza

To ty chyba nie bawiłeś się w ograniczone konta na XP i całą zabawę z aplikacjami... UAC jest miłe i przyjemne...

znalazłem gdyby ktoś chciał ścieżkę do np. APPDATA w stylu:
C:\Users\NazwaUżytkownika\AppData\Roaming

FPC (only?): http://www.freepascal.org/docs-html/rtl/sysutils/getappconfigdir.html
Działa nie tylko pod Windowsem ale też linuxem etc.

Ale młodzi ludzie i zwłaszcza programiści nawet amatorzy powinni wedlug mnie sobie ułatwiać życie róznymi narzędziami.

Nigdy się nie przyzwyczaiłem do Total Commandera, czy to znaczy że utrudniam sobie życie? Po prostu to samo zrobię szybciej bez niego.

Nie sprawdzałem z UAC, ale UAC powinien pozwolić tworzyć tam folder + plik INI?

Raczej tak.

0

powinieneś raczej użyć SHGetFolderPath z CSIDL_LOCAL_APPDATA bo zmienną środowiskową każdy może sobie w każdej chwili zmienić i nie jestem pewny czy poleganie na niej to będzie bug czy feature ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1