Az „Excel” fórum célja, hogy keretet adjon az Excel felhasználók széles táborának tapasztalataik megosztására, és lehetőséget a segítséget kérőknek. Az alábbi összefoglaló azért készült, hogy segítse a helyes kérdésfeltevést.
– Írd le szabatosan a problémát. Úgy fogalmazz, hogy ne csak te magad, de a szakértő is megértse, mire szeretnél választ kapni.
– Írd le, hogy milyen verziójú Excellel dolgozol. (Vagy ha nem – ill. nem csak – Excel, akkor micsoda?)
– Írd le, hogy milyen úton indultál el, és hol akadtál el rajta.
– A kérdés megértése szempontjából sokat segíthet, ha feltölteszt egy képet, amin látszik, hogy mit szeretnél, vagy illusztrálja azt.
– Még jobb, ha feltöltesz egy minta munkafüzetet valahová (pl. data.hu). Feltöltés előtt távolítsd el belőle a nem publikus adatokat.
– Ha a feladat jellege olyan, célszerű az "előtte" és "utána" állapotokat bemutatni. (Miből kellene csinálni mit?)
– Ha VBA kódon kell javítani, másold be a releváns kódrészt. Rövid kód mehet hozzászólásba, hosszú kód inkább ide: http://pastebin.com/
– Ha valami nem úgy működik, ahogy kellene, add meg a rendellenes viselkedés jellemzőit, a hibaüzenetet, és a hibát okozó programsort.
Le tudnád írni kicsit egyértelműbben, hogy mi a gond? Ha egyesítek n darab cellát (ami alapból már zárolt, ugye), és levédem a munkalapot, nekem védettnek tűnik az egyesített tartomány. Legalábbis nem tudok bele írni.
Egy matematikai technikával is megoldható, ha mindig 4 üres cellát követően jönnek a szükséges adatok. Ekkor a 2-es munkalapon az A1-be írd a következőt: =INDIREKT("Munka1!A" & (SOR()-1)*5+1)
Ha az 1-es munkalap neve nem Munka1, akkor azt írd a felkiáltójel elé (Ha véletlenül több szavas, akkor még aposztrofok közé is kell tenned a munkalap nevét). És ezt húzd végig lefelé.
Köszönöm, ez nagyon jó, sajnos nem jutott eszembe, pedig szoktam néha használni! :)) Viszont most ezt nem tudtam használni, mert a szoftver eleve Excel-be írja az adatokat, tehát nem kell beolvassam (bár tudja szövegfile-ba is, de azzal sok baj van, mert minden adat ömlesztve lesz kiírva, hosszabb-rövidebb szóköz-sorozatokkal elválasztva, akkor inkább menjenek egyenesen az adatok az Excelbe, külön-külön munkalapra az összetartozó értékek, és rendesen kerüljön táblázatos formába mindaz, ami táblázatos jellegű). Azért köszönöm az emlékeztetést, egyszerű, szép megoldás!
Jimmy the Hand! Köszönöm szépen! Remekül működik, tök jól lehet vele ellenőrizni! 1000 hála és köszönet!
De rögtön jött egy másik kérdés. Az feltűnt már eddig is, amit most ezzel a megoldással látok is, hogy az egyesített cellákat nem védi le az excel. A védelemre egyébként egy nyitási makrót írtam, mivel a táblát folyamatosan töltik a kollégák és változnak a védendők. A makró lényege annyi, hogy feloldja a lapvédelmet, sorban kijelöli az írható blokkokat és az üres cellákat (mert ezekbe még írhatnak) és ezeket fel is oldja a védelem alól, majd az egészet levédi. Viszont az egyesített cellákat valamiért nem. Nem óriási probléma, de ha esetleg van ötlet rá, azt nagyon megköszönöm!
Szeretném megkérdezni, hogy egy összetett táblázatot tartalmazó oldalakon, ahol vegyesen vannak védett és nem védett cellák is "össze-vissza"; valahogy ki lehet-e mutatni, hogy melyik cella védett, és melyik nem. Szeretném ezt tenni ellenőrzés céljából a táblázat elkészítése után, hogy ne próbálgatással kelljen megnéznem, hogy a megfelelőeket védtem-e le és amit kell, azt szabadon hagytam-e. Lehet ez egy lista, vagy kiszínezés, vagy hasonló, ahol áttekintően látom, hogy jól dolgoztam-e.
Esetleg próbáld meg a szövegfájl beolvasását a felső menüben az Adatok->Külső adatok átvétele menüben a szövegből történő beolvasással megnyitni.Itt az adott oszlopnál az 'irányított' gombra kattintva ki tudod választani a beolvasandó fájlban használt tizedespontot:
Köszönöm! Nem egyszerű, mert vannak üres cellák is (bár ezekkel nincs gond) és szöveges cellák is vannak, miközben mindent (a számokat is) szövegnek vesz az Excel. Még töprengek egy gyors és egyszerű módszeren. A tipp mindenesetre hasznos, köszönöm!
A Val() függvény jól megérti a tizedespontot, szóval ha tutibiztos, hogy a szöveges értékeid kizárólag tizedespontot tartalmazó számok, akkor megteheted azt, hogy cellánként lecseréled az értéket:
cella.Value = Val(cella.Value)
Így biztos, hogy a cellában szám lesz, és csak a megjelenési formája függ az adott gépen érvényes területi/nyelvi beállításoktól.
Vannak nyers adataim (egy más szoftverből kapott kimeneti szövegfile-ban), amit Excel-ben szeretnék tovább feldolgozni és kiértékelni. A tizedespontok a szövegfile-ban '.' ám nálam az Excelben ',' kellene legyen. Egy trükkös megoldást találtam (még régen ti mutattátok itt, azóta is használom):
Sub SetFormat() Dim Displ As Worksheet For Each Displ In Worksheets With Displ If Not .Name = ExpJointsName And Not .Name = ResName Then .Columns("B:G").Replace What:=".", Replacement:=".", LookAt:=xlPart, _ SearchOrder:=xlByRows, MatchCase:=False, SearchFormat:=False, _ ReplaceFormat:=False .Columns("B:D").NumberFormat = "0.000" .Columns("E:G").NumberFormat = "0.0000" End If End With Next Displ End Sub
Ez bár működik, de gyanítom, hogy más Windows-os területi beállítások mellett nem fog működni! Mit kellene tegyek, hogy a szövegfile '.' tizedespontjával megadott számértékeket az Excelben minden tizedespont beállítás mellett számkért értelmezve tudjam kezelni? A Replacement:="." helyett kellene valami univerzálisabb megoldás. Talán le kellene kérdezni az aktuális beállítást, mi a tizedespont, és ha az nem '.' (ami a nyers adatokban), akkor arra cserélni a nyers adatok tizedespontjait, amit az Excel elvár. De ezt hogyan?
Bár a HA függvény látszólag adja magát, és elsőre talán logikusnak tűnik a használata a feltételes formázásban, valójában egyáltalán az.
A feltételes formázás képletének egy logikai IGAZ vagy logikai HAMIS eredményt kell adnia, ez alapján vagy érvényesül a megadott formázási szabály, vagy nem.
Viszont a HA függvény maga is azt csinálja, hogy kiértékel egy feltételt, és a feltétel teljesülése esetén az egyik, nem teljesülése esetén a másik értéket adja vissza eredményként.
Így ha eleget akarunk tenni a feltételes formázás elvárásainak, tudniillik, hogy a képletünk IGAZ/HAMIS eredményt szolgáltasson, akkor a HA függvényt csak az alábbi formában tudjuk használni:
=HA(<valami feltétel>;IGAZ;HAMIS)
Ám itt valójában semmi mást nem teszünk, mint hogy kiértékeltetjük a feltételt a HA függvénnyel, teljesen feleslegesen, hiszen ugyanezt a kiértékelést a feltételes formázás szabálykezelője is el tudja végezni. Tehát eredményét tekintve a fenti képlet egyenértékű azzal, hogy teljesen elhagyjuk a HA függvényt:
=<valami feltétel>
Összefoglalva: a HA függvény használata a feltételes formázásban nem tilos, működik is, viszont felesleges, mert csak bonyolultabbá teszi a képletet, lassítja a végrehajtást, és eltereli a figyelmet a lényegről, mely utóbbi a <valami feltétel> szabatos megfogalmazása lenne.
Szeretnék segítséget kérni feltételes formázással vagy egyéb módon hogy tudom megoldani egy táblázaton belül hogy minden második sor háttere legyen szines, de csak akkor ha a sor valamely cellája értéket tartalmaz.
Köszi a hozzászolást megoldódott, nekem valahogy nem esett le ez a szöveges dolog.
A hiba az volt hogy a táblázatban az összes adat mögött ott volt a "g" gramm emiatt beolvasta de nem adta össze, miután kitöröltem a szöveget a bázis táblából így már összeadja és a cellaformázásnál pedig beállítom a számot egyénire mögé írva egy "g" ot és tökéletes kiadja amit akarok.
Nem jártam messze tőle de nem esett le szóval köszi még egyszer.
Amúgy valóban számok vannak azokban a cellákban? Attól hogy egy érték az FKERES függvény eredménye, attól még a SZUM függvénynek vígan össze kellene adnia, feltéve, hogy szám. De pl. olyat, hogy 17g + 92g + 32g, olyat nem fog a SZUM összeadni, mert ezek szövegek, nem számok.
(Fura ez, mert aki legördülő listát létre tud hozni, annak a fentieket csípőből vágnia kellene, de a kérdésed megfogalmazásából nekem ez jutott eszembe.)
ebből az adathalmazból csináltam egy legördülő listát majd a mellette lévő cellákba az "FKERES" függvénnyel beolvastattam a hozzá tartozó fehérje szénhidrát stb adatokat
Mivel étkezésekre van bontva pl egy étkezés 6 sort tartalmaz ahova mindenki beirhatja hogy reggeli pl eszik kenyeret joghurt zabpehely stb a végén szeretném összeadva látni hogy az étkezés mennyi fehérjét zsirt tartalmaz de a "SZUM" függvény nem veszi figyelembe mivel amiket összekéne adnia cellákban ugyan én látom az értéket de valójában ugye az "FKERES" függvény van benne.
Van e valakinek valami ötlete hogyan lehetne az Fkeres által kiadott eredményeket összeadni illetve megszorozni pl.
Na egy ilyen ember előtt én is leborulnék. Einstein sem tudná eldönteni az 123,123 karaktersorozatról (ha csak ennyit lát), hogy az mi is valójában.
Annak mondjuk van némi realitása, hogy a szövegkörnyezetet megvizsgáljuk programmal, és abból következtessünk. Ha pl. a forrás szöveg kizárólag olyan - felismerhető - számokat tartalmaz, amelyeknél a tizedesjel pont, akkor feltételezhető, hogy az 123,123 is ilyen, csak nincs tört része. De csak feltételezhető. Mert mi van, ha ez itt épp egy kivétel. Tegyünk a kódba szövegértelmező algoritmust is? Hát... akkor már inkább ráhagyom a felhasználóra a döntést.
Ember legyen a talpán, aki teljesen kötetlen szövegre talál erre egy biztos algoritmust, ami jól behatárolja az előjelet, helyiértéket, tizedeshelyet (Regexszel)
Elég sokat izzadtam a témával, és nem sikerült megtalálnom a bölcsek kövét.
Valóban akkor van a legnagyobb probléma, ha az egy szem tagolójel után még három számjegy jön.
De egyéb esetekben is előfordulhat, hogy olyan helyesírási hiba van a számban, amit a humán olvasó a szövegkörnyezet alapján tud korrigálni, vagy olyan, amit a humán olvasó sok utánjárással tud dekódolni, de gépi átalakításkor bizony információt veszíthetünk. Ha egy jól definiált speciális esetet meg tudsz oldani, már vállon veregetheted magad.
Igazából rövid távon nem gond, mert a szövegfájlokat, amelyeket fel akarok dolgozni, programok állítják elő, és így egész korrekt feltételezéssel tudok élni mindegyik esetben. Csak szerettem volna egy általánosabb megoldást, amit egy ctrl+c/ctrl+v kombóval be tudok tenni akármelyik későbbi programomba. De odáig nem terjed az önbizalmam, hogy majd pont én fogom megírni a Nostradamus-algoritmust, szóval a nem szabályos alakokat valószínűleg kivételként fogom kezelni. Meglátjuk.
