Witam
Obecnie skrypt sprawdza początek nazwy w DB:
procedure MasterData12OnBeforePrint(Sender: TfrxComponent);
begin
if Copy(<pdfv."feature_value">, 1, 4) = 'Syne' then
MasterData12.Visible := True
else
MasterData12.Visible := False;
end;
Czasami szukany wyraz jest drugi lub dalej. Jak zrobić aby szukał nie tylko na początku ciągu znaków ale również w środku.
Jeżeli szukamy jakiegokolwiek wystąpienia frazy to może:
procedure MasterData12OnBeforePrint(Sender: TfrxComponent);
var
strTmp : String;
begin
strTmp := <pdfv."feature_value">; //tutaj spróbuj z klamrami <> lub bez
if Pos('Syne', strTmp) > 0 then begin
MasterData12.Visible := True;
end else begin
MasterData12.Visible := False;
end;
end;
WOW...
Szybka odpowiedz... a na dodatek trafna.
To działa :)
Dzieki
Teraz jeszcze muszę to przeanalizować i zrozumieć. Jeszcze raz dzięki.
Ten framgent z Pos można uprościc, po co tyle begin i end:)
MasterData12.Visible := Pos('Syne', strTmp) > 0;
@Kristof: słuszna, uwaga, ale ja bym jeszcze zrobił małą korektę i zapisał to tak:
MasterData12.Visible := (Pos('Syne', strTmp) > 0);
Moim zdaniem taki zapis jest czytelniejszy i od razu widać, że całe wyrażenie tworzy jedną całość. Oczywiście - Twój zapis jest OK, ale ja preferuję (w odróżnieniu od pewnej grupy osób, dla których maksymalna zwięzłość i krótkość są priorytetem) zapis może i trochę dłuższy, ale za to czytelniejszy i bardziej oczywisty ;)
cerrato napisał(a):
@Kristof: słuszna, uwaga, ale ja bym jeszcze zrobił małą korektę i zapisał to tak:
MasterData12.Visible := (Pos('Syne', strTmp) > 0);
Taaa... można i tak.
A ja bym użył filtrowania na poziomie bandy bezpośrednio w FastReport (od wersji 6.x jest to dostępne) bez babrania się skryptami.
Albo, dla poprzednich wersji, filtrowania na poziomie DataSetu i ustawienie MasterData12.VisibleIsEmpty (jeśli dobrze pamiętam nazwę właściwości) na False.
Efekt ten sam, ale różnice pojawią się kiedy danych będzie duuuużooo...
Chociaż, po prawdzie, nie będą jakieś super znaczne.
Zatem, niech będzie że możliwości na osiągnięcie celu jest kilka, a wpis ma na celu tylko ich prezentację :)
Moim zdaniem taki zapis jest czytelniejszy i od razu widać, że całe wyrażenie tworzy jedną całość. Oczywiście - Twój zapis jest OK, ale ja preferuję (w odróżnieniu od pewnej grupy osób, dla których maksymalna zwięzłość i krótkość są priorytetem) zapis może i trochę dłuższy, ale za to czytelniejszy i bardziej oczywisty ;)
Też można, ale jak rozumiem kod (to tylko prezentacja, żaden w tym kodzie sens) piszesz w ten sposób?
if (Value = 1) then
begin
ResValue := 1;
end
else
if (Value = 2) then
begin
ResValue := 2;
end;
Masz tu "czytelne" rozróżnienie wyrażeń i całych bloków po spełnieniu warunku.
Ale to przerost formy...
Nic a nic ten Twój zapis czytelniejszy jest, a wprowadza tylko niepotrzebne nawiasy i sporo nadmiarowości, której nie lubię kiedy sens w tym żaden.
Można, ale nie trzeba.
Za czytelniejszy uważam taki:
if Value = 1 then
ResValue := 1
else
if Value = 2 then
ResValue := 2;
Tylko teraz dałeś przykład mocno przejaskrawiony :p
W tym pierwszym przykładzie beginy i endy są przegięciem. Ja bym zrobił to w formie drugiego kodu, ale warunki przy if bym dał w nawiasach.
Przy czym to są kwesrie głównie edycyjne. Tak samo, jak np. sposób pisania = oraz :=. Przed i po pierwszym daje spacje, ale w przypadku operatora przypisania u mnie spacja jest tylko za nim, z lewej strony jest przyklejony do zmiennej :D
@Kristof podał sposób który preferuję – uniknięcie warunku, brak nadmiarowości w postaci niepotrzebnych nawiasów. @wloochacz też podał dobry przykład – wywalenie zbędnych bloków grupujących dla pojedynczych instrukcji. Im mniej warunków i bloków, tym kod krótszy i łatwiej go analizować.
Ale wiadome – nie zawsze usunięcie warunku na rzecz bezpośredniego przypisania wyniku wyrażenia zwiększa czytelność kodu, więc nie ma co przesadzać czy wręcz na siłę wprowadzać takie krótkie formy, bo powstaną jednolinijkowce, których po tygodniu nikt nie zrozumie.
cerrato napisał(a):
Tylko teraz dałeś przykład mocno przejaskrawiony :p
Oczywiście i tylko po to, aby pokazać ze Twoje propozycje są... mało życiowe.
W tym pierwszym przykładzie beginy i endy są przegięciem. Ja bym zrobił to w formie drugiego kodu, ale warunki przy if bym dał w nawiasach.
To jest jeden warunek, a więc po co nawias?
Ponieważ poprawia czytelność? Nie zgadzam się z tym.
Ale domyślam się z czego to może się brać; mój współpracownik tak pisze, ale tylko dlatego że nie widzi intuicyjnie wyrażeń logicznych.
Ale ja tak.
I dlatego on pisze nawiasy nawet tam gdzie są niepotrzebne (np. if (Value1 or (not Value2)) then cos_tam), a ja nie.
Przy czym to są kwesrie głównie edycyjne. Tak samo, jak np. sposób pisania
=oraz:=. Przed i po pierwszym daje spacje, ale w przypadku operatora przypisania u mnie spacja jest tylko za nim, z lewej strony jest przyklejony do zmiennej :D
Nie lubię asymetrii i zęby mnie bolą jak widzę coś takiego (spacja przed, ale nie po itd.).
Ale mnie to ani grzeje, ani ziębi, ponieważ da się to ustawić a w automatycznym formatterze kodu.
Dlatego jaki mi ktoś pisze taki bajzel, to sobie zapuszczam formattera i jest OK.
Czyli podsumowując Twój poprzedni post:
1) Dałeś przykład z czapy, z którym nie mam praktycznie nic wspólnego, żeby udowodnić jakąś swoją tezę, która nie wynika z moich wypowiedzi. Tak, to ma sens :D
2) Współpracownika nie znam, więc się nie wypowiem. Odnośnie mnie - ja akurat umiem dostrzec i zrozumieć, co oznacza zapis Pos('Syne', strTmp) > 0, ale mimo wszystko i tak uważam, że z nawiasami jest czytelniej
3) Pisze nawiasy nawet tam gdzie są niepotrzebne - to jest Twoja subiektywna ocena, co jest potrzebne. Tak samo niepotrzebne są wcięcia na początku linii, odstępy przed i po znaku równości, przed/po nawiasach itp.- bez nich przecież też się skompiluje. To jest jedynie kwestia estetyki i czytelności, a jak widać - różne osoby mają na to odmienne spojrzenie
4) Nie lubię asymetrii i zęby mnie bolą jak widzę coś takiego (spacja przed, ale nie po itd.)odnośnie bólu zębów, proponuję się skonsultować z dentystą, może to początki czegoś poważniejszego. Poza tym jest takie zdanie (przypisywane Picasso, później wykorzystane przez Tuwima) że "symetria jest estetyką głupców" :P. OK, może Ci się nie podobać, kwestia gustu. Dla mnie ważniejsza jest konsekwencja - jeśli programista zdecyduje się gdzieś stawiać spacje/wcięcia, to niech będzie w tym konsekwentny i robi tak wszędzie.
5) "współpracownik [...] nie widzi intuicyjnie wyrażeń logicznych, ale ja tak." - chciałem napisać coś złośliwego na temat ego pewnych osób, ale się powstrzymałem ;)
cerrato napisał(a):
Yhm... jak zwykle w Twoim wykonaniu wpis "w punkt".
Szkoda prądu, drogi kolego, absolutna strata energii na dalszą dyskusję o niczym.