Czy można otworzyć dialog utworzony w Visual Studio pod Delphi z zasobów?

Można otworzyć dialog utworzony w Visual Studio pod delphi (w tym tekstowym formacie - rc, co potem kompilujemy do res)?

Pokaż tutaj tresc, jak wygląda taki plik. A i zawsze możezz spróbować użyć ResEd z: http://www.oby.ro/rad_asm/resed/index.html i pod nim zapisać z odpowiednią opcją w ustawieniach, tak aby plik zasoboów był kompatybilny z kompilatorami Borlanda. Cięzko mi coś doradzić, bo swoje *.rc z dialogami używam w zasadzie tylko w moich kodach WinAPI. A do nich żeby exek nie spasł się za bardzo, używam Delphi 7 Personal i na ogół jeszcze UPX'uje exeka.

Od tak - nie.
Ale da się napisać odpowiednie oprogramowanie.

Jeżeli program w Delphi piszesz w WinAPI, to możesz użyć skompilowanego .resa w programie pisanym w Delphi.
Zwykłe

{$RESOURCE plik.res}

powinno wystarczyć.

Ale nie otworzy ci tego standardowy edytor form tak do edycji.

Jak to wtyknąć w exe to ja wiem.
Chodzi mi czy tam istnieje specjalna klasa która łapie taki dialog.

Powiedzmy że byłby to typ TResourceDlg, do obsługi takich dialogów,
znaczy tworzymy taki obiekt, podając w konstruktorze identyfikator tego resourca,
a potem robię dlg.Execute, i to otworzy okno...
plus jakieś funkcje virtualne, odpalane do zainicjowania, np. wpisanie tekstu do edit, check, radio, wypełnienia listbox, itp.

Powiedzmy że byłaby to procedura w stylu:
virtual bool TransferData(in/out), którą sobie tylko redefiniujemy.

Po naciśnięciu OK znowu ta funkcja jest odpalana, ale z parametrem out nie in, czyli czytamy wpisane dane.

Jest tam coś takiego?
Powinno chyba być, bo te common dialogs: openfile, print, font, color,
byłyby wtedy mocno ograniczone - niemożliwe do modyfikacji, poprzez wsadzenie 'custom dialog template'.

Dialog z resource'ów otwieramy za pomocą funkcji WinAPI - CreateDialog, DialogBox albo jeden z wielu ich wariantów.

Chcesz klasę to sobie opakuj, bo w VCL raczej nic takiego nie ma.

"common dialogs" to są gotowe szablony wbudowane w Windowsa (dlatego są "common") i nie sądzę żeby Delphi mieszało w tych szablonach.

A swoją drogą to nie wiem czy w ogóle warto się w to bawić, łatwiej przecież zrobić formatkę od nowa niż kombinować.

W skrócie: jeśli ci DialogBox() z resource'em nie wystarcza, zrób normalną formę.

Tworzenie tych form raczej odpada, ponieważ mam dość dużo tych dialogów, zatem po przerobieniu na formy
byłoby pełno oddzielnych unitów - plików pas, pomijając to że samo projektowanie od nowa tych dialogów - form wymagałoby sporo roboty.

Mówisz że w Delphi nie da rady modyfikować common dialogs,
np. dołożyć kontrolkę przy wydruku, albo dorobić własny podgląd w tym openfiledialog?

ptic napisał(a)

pomijając to że samo projektowanie od nowa tych dialogów - form wymagałoby sporo roboty.

Napisz sobie translator takich plików :P (w każdym razie ja bym tak zrobił; ew.poszukaj jakiegoś gotowego)

Patryk27 napisał(a):

ptic napisał(a)

pomijając to że samo projektowanie od nowa tych dialogów - form wymagałoby sporo roboty.

Napisz sobie translator takich plików :P (w każdym razie ja bym tak zrobił; ew.poszukaj jakiegoś gotowego)

Już wolałbym przerobić kod na C++, bo jest tego niewiele, zamiast grzebać się w pięćdziesięciu formach...

I nie ma do tego gotowców, bo kiedyś szukałem czegoś takiego.
Ludzie od Delphi nie znają się zwykle na wewnętrznych detalach Windows, więc i nie potrzebują takich rzeczy.

Mówisz że w Delphi nie da rady modyfikować common dialogs,

Nie mam Delphi żeby sprawdzić, ale z punktu widzenia WinAPI te wszystkie common dialogs to są gotowe okienka wbudowane w Windowsa: jest jedna funkcja którą odpalasz, z ograniczoną możliwością ingerowania za pomocą parametrów wywołania tej funkcji. Tak samo jak MessageBox.

Delphi mogłoby reimplementować całe okienko, ale to byłoby dziwne, i już nie byłoby "common dialogs".

Wracając do problemu: jak masz resource'owe dialogi, to otwieraj je normalnie tak jak pod C++, za pomocą służących do tego funkcji WinAPI.
Chcesz mieć wygodę VCL-owych form, to wyklikaj formę na nowo.

A jeśli chcesz do GUI napisanego w C++ dodać kod napisany w Delphi, to skompiluj to delphi do DLL-ki i załaduj w programie w C++.

Azarien napisał(a):

Mówisz że w Delphi nie da rady modyfikować common dialogs,

Nie mam Delphi żeby sprawdzić, ale z punktu widzenia WinAPI te wszystkie common dialogs to są gotowe okienka wbudowane w Windowsa: jest jedna funkcja którą odpalasz, z ograniczoną możliwością ingerowania za pomocą parametrów wywołania tej funkcji. Tak samo jak MessageBox.

Głupoty opowiadasz.
Możesz zmienić i wsadzić tam swój własny dialog - template, zachowując oczywiście te stare kontrolki
(jeśli chcesz żeby czegoś tam nie było możesz zrobić to hidden, albo przesunąć całkiem poza ramy,
i wtedy nie będzie tego widać).

Azarien napisał(a):

Delphi mogłoby reimplementować całe okienko, ale to byłoby dziwne, i już nie byłoby "common dialogs".

Dziwne jest raczej to vcl z delphi.
Przecież to jest gorsze nawet od tych obiektów MFC.

Niemal każda poważniejsza aplikacja ma zmodyfikowane - dostosowane printdialog i openfile,
a te do wyboru czcionek i kolorów to zupełnie są zwykle pozmieniane.

Dziwne jest raczej to vcl z delphi.
Dialogi systemowe są po to aby ich używać, a nie wynajdywać koła na nowo. Nie po to Windows ma własne, standardowe okienko do wyboru pliku, by robić własne, na 90% gorsze lub brzydsze.

Azarien napisał(a):

Dziwne jest raczej to vcl z delphi.
Dialogi systemowe są po to aby ich używać, a nie wynajdywać koła na nowo. Nie po to Windows ma własne, standardowe okienko do wyboru pliku, by robić własne, na 90% gorsze lub brzydsze.

Fakt, musiałbyś robić własne od zera, gdybyś chciał coś tam dodać, lub zmienić.
Ja nie muszę, bo zmieniam tylko te gotowce, wg zaleceń MS:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646951%28v=vs.85%29.aspx

ptic napisał(a)

Dziwne jest raczej to vcl z delphi.
Przecież to jest gorsze nawet od tych obiektów MFC.

Nie pisz że coś jest dziwne, skoro tego nie rozumiesz; Po to system udostępnia gotowe - wbudowane okna, żeby programy korzystały z czegoś, co będzie takie same w całym systemie; Dlatego też system narzuca cały wygląd tworzonych aplikacji, żeby każda z nich korzystała z tego samego co cały system;

ptic napisał(a)

Niemal każda poważniejsza aplikacja ma zmodyfikowane - dostosowane printdialog i openfile,
a te do wyboru czcionek i kolorów to zupełnie są zwykle pozmieniane.

Bo jeśli twórca programu uzna, że systemowe okno dialogu ma za mało bajerów lub uzna, że systemowe jest wieśniackie to robi swoje, które nie dość, że rozbuduje bez zbędnych kombinacji, to jeszcze dopasuje takie okno do interfejsu całego swojego programu; Jeśli tworzy się program bez ingerencji w jego GUI to można śmiało korzystać ze wszystkiego, co oferuje system;

Ale wyobraź sobie teraz taką sytuację, że tworzysz program z własnym GUI (własny wygląd formularza + własne komponenty) i przychodzi czas na okna dialogowe; Cały program ma własny wygląd, a okno dialogowe (to systemowe) ma zupełnie inny; Wtedy przychodzi czas na stworzenie własnego, który będzie wyglądał tak, jak pozostała część programu, a dodatkowo będzie wyglądać tak samo na wielu wersjach Windowsa, które jak wiadomo każdy kolejny ma zupełnie inny interfejs;

Azarien napisał(a)

Nie po to Windows ma własne, standardowe okienko do wyboru pliku, by robić własne, na 90% gorsze lub brzydsze.

Tutaj się nie zgodzę - Windows ma swoje gotowe okna po to by z nich korzystać bez własnych implementacji, na które trzeba poświęcać czas; Każdy może zrobić własne okno dialogowe, które może być nie dość, że bardziej funkcjonalne to ładniejsze lub dostosowane dizajnem pod wygląd całej aplikacji; Z jednej strony system i tak narzuca wygląd całej aplikacji (jeśli korzysta się z gotowych komponentów), ale jak ma się swoje malowanie GUI to tylko ktoś niepoważny wykorzysta systemowe okno, psując cały efekt, jak na poniższej ilustracji:

Uwaga! Powyższa ilustracja to fotomontaż - program Odkurzacz w wersji 13 nie wykorzystuje systemowego okna dialogowego; Obraz przygotowany jedynie do przedstawienia swoich poglądów;

Jeśli ktoś chce zepsuć wygląd aplikacji systemowym badziewiem to jego wybór - ja osobiście wolałbym poświęcić czas na zaimplementowanie swojego okna z własnymi komponentami.

Pierdoły opowiadać bez ładu i składu.
Modyfikowanie common dialogs nie zmienia wbudowanego działania danego okna, ani jego wyglądu, ponieważ np. dodany button, static, combo, itd.
będzie rysowany zgodnie z aktualnym stylem - kolory, motywy, cienie i inne te skecze z commctrl ver 5, 6, czy też 10 za kilka lat.

Nie ma w delphi w pełni obiektowej obsługi elementów windows, więc nie ma... cześć i czołem.

Modyfikowanie common dialogs nie zmienia wbudowanego działania danego okna, ani jego wyglądu, ponieważ np. dodany button, static, combo, itd. będzie rysowany zgodnie z aktualnym stylem - kolory, motywy, cienie i inne te skecze z commctrl ver 5, 6, czy też 10 za kilka lat.

A kto napisał, że nowe elementy będą z innego stylu? Czytaj ze zrozumieniem;

Nie ma w delphi w pełni obiektowej obsługi elementów windows

No nie ma - to fakt, dlatego nie jest to takie proste jak w innych językach, które taką możliwość udostępniają.