Markera portalrad

Tråden skapades och har fått 6 svar. Det senaste inlägget skrevs .
1

Är lite konfunderad... har en kanon bra bok till hjälp (special edition using filemaker 8) när jag utvecklar och har där följt ett tips om hur jag markerar portalrader med en färg. Har skapat följande fält:
- 1 st beräkningsfält i ArtikelRad registret (z_RadMarkering_cc), ser ut som följer:
If(
zdev_GlobalVar::MarkeradRad_gn = __kp_HusArtikelID;
zdev_GlobalVar::MarkeradRadFärg_gc;
""
)

- 1 st globalt fält av typen numer i mitt globala register ( zdev_GlobalVar::MarkeradRad_gn).
- 1 st globalt fält av typen container i mitt globala register där jag har en bild med markeringsfärgen (zdev_GlobalVar::MarkeradRadFärg_gc)

Har följt bokens exempel till punk o pricka förutom att jag inte skapat de globala fälten i ArtikelRad utan i ett separat register (zdev_GlobalVar). Detta för att jag kommer vilja använda markering av portalrad i flera portaler.

Nu till frågan; jag får det inte att fungera om jag inte lägger in fältet zdev_GlobalVar::MarkeradRad_gn i layouten där portalen finns. Borde inte beräkning i fältet z_RadMarkering_cc "komma åt" ett globalt fält utan att den ska behöva ligga på samma layout??? Tycker det är riktigt märkligt... Tacksam om någon kan förklara detta.

Det är inte så märkligt, det har med relationer att göra och att FileMaker inte uppdaterar saker som ligger för "långt bort" om du inte uttryckligen säger till om det.

Det finns en anledning att boken använder globala fält i tabellen artikelrader.

Hmm.. ok, tycker bara att är det ett globalt fält så ska det vara tillgängligt överallt. Är det så att jag måste ha en relation från registret med globala fält till artikelrad eller räcker det med att det finns bland tabellförekomsterna?

För att FileMaker skall "se" ett relaterat fält måste det finnas en relation till det ja.

På min gamla FileMaker-webbsite så har jag ett exempel på hur man kan markera en viss post i en lista med en annan färg, men man måste bläddra upp och ner med knappar för att det skall fungera. Exemplet är gjort för FM 7 och framåt.

Markera post i lista med egen färg (http://kurser.intelligentmammals.se/fm/ )

Ett globalt fält ÄR tillgängligt överallt om du med överallt menar alla poster i samma tabell. Du är också medveten om antar jag att varje användare av en databas har sin egen uppsättning med globala fält, så du kan alltså inte bygga en funktion där en användare markerar något som skall ses av en annan. (Klart att det går men inte med variabelfält).

Du utelämnar en del viktig info i din fråga (hur relationer och beräkningar ser ut mm), så det är inte helt lätt att svara på. Men om jag förstår dig rätt så har du en layout som visar poster från en tabell. I den layouten finns en portal som visar relaterade poster i en annan tabell. Sedan har du dessutom tänkt dig att i varje portalrad visa information från en tredje tabell till vilken du inte har någon relation (mellan tabell två och tre alltså). När du sedan gör en ändring i något (antingen i tabell 1, eller i portalen i tabell 2) är du förvånad över att tabell tre inte påverkas?

Det är som jag sade, ditt tänk omkring relationer är förmodligen fel, eller så är det så att Filemaker inte uppdaterar tabell 3 som du vill.

Jag har gjort just exakt det du vill göra några gånger och för att få till detta måste man faktiskt "hoppa" till posten i tabell 3, verkställa den posten eller på något sätt "peta på den", sedan hoppa tillbaka till tabell 1, verkställa den posten med och då först syns ändringen i portalen.

Jag hade en funktion där man på en patient kunde har flera behandlingsplaner och med en knapp kunde man markera vilken som var aktiv, vilket gör att det i portalen skrivs ut "Aktiv", vilket liknar ditt problem.

Tack för dina inlägg Taz, ska försöka beskriva hur det ser ut.

Aktuella tabeller är:

Offert
HusArtikel
z_dev_GlobalVar

Offert och HusArtikel är relaterade med varandra genom _kf_HusID och ett filtreringsfält för att filtrera artiklarna per kategori. z_dev_GlobaVar innehåller endast globala fält och är inte relaterat alls, finns bara bland tabellförekomsterna.

I HusArtikel finns följande beräkningsfält: z_Radmarkering_cc som ser ut som följer:

If(
  zdev_GlobalVar::MarkeradRad_gn = __kp_HusArtikelID; 
  zdev_GlobalVar::MarkeradRadFärg_gc;
  ""
)

MarkeradRadFärg_gc är ett container fält och innehåller en bild med radfärgen. Använder alltså z_dev_GlobalVar i beräkningen men inte som fält i portalen.

Jag står sedan i en layout som visar poster från tabellen Offert och har en filtrerad portal som visar HusArtikel tabellen. Beräkningsfältet ligger i bakgrunden i portalen med en knappfunktion som anropar ett skript som utför följande:

Tilldela fält[z_dev_GlobalVar::MarkeradRad_gn; Offert_HusArtikel_Filter::__kp_HusArtikelID]
Verkställ post/sökpost[Ingen dialogruta]

När jag provar att köra med datavisaren visar den att MarkeradRad_gn får nyckeln från HusArtikel men beräkningen verkar inte kunna komma åt den. Men om inte jag lägger in fältet MarkeradRad_gn på layouten så funkar det galánt. Det är det som förbryllar mig, att bara därför fältet finns på layouten så kan den "se" fältet fast ingen relation finns i tabellförekomsterna.

Jag ska sedan använda denna layout för att filtrera fram rätt artikel och infoga denna i offertrader.

Puh, hoppas du förstår vad jag menar...

Hmm, jag skapade en ny tabellförekomst och en relation mellan HusArtikel och z_dev_GlobalVar baserat på __kp_HusArtikelID och MarkeradRad_gn. Fungerar fint och kanske är en snyggare lösning...

Snyggt är en relativ term. Att du har skapat en extra tabell för dina variabler innebär just att du har en extra tabell och en extra relation och eventuellt då även en extra layout och en extra tabellförekomst, för att lagra några variabelfält som du lika gärna kunde ha i den aktuella tabellen istället. Om det är snyggt eller ej kan man dividera om och även om det finns regler för databasdesign (normaliseringsregler) så nämns inte just detta specifika exempel.

Som jag nämnde var det nog kanske ett feltänk i dina relationer, att FileMaker i layouten verkar "se" dina globala fält i den separata tabellen utan relationer först när de ligger i layouten har alltså inget att göra med att beräkningen (som utvärderas utifrån en angiven tabellförekomst) också kan "se" eller inte "se" de fälten. Genom att skapa en relation mellan de sakerna så får FileMaker de ramar och regler den vill ha för att kunna göra rätt så att säga. FileMaker har ingen anledning att uppdatera dina variabelfält om det inte finns en relation till dem. Så lika bra att göra en.

Kul att det löste sig.

1
Bevaka tråden