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.
És a nyolcadik utast sokan hetedik utasnak hívják, mert nullától szokás számolni. Tehát a jobb szélső bit jobbról a nulladik...
A legmagasabb helyiértékű bit annyiban helytálló, hogy bármely egészt tekinthetünk előjel nélkülinek, és akkor tényleg az a legmagasabb helyiértékű; az meg nem magában a számban rejtőzik, hogy előjeles vagy sem, hanem az értelmezésen.
Ha egy kupac számot elmentesz és nem mondod meg hozzá az adatszerkezetet, akkor amúgy sem lehet rekonstruálni az értéküket. (Hány bitesek? Big vagy little endianként tárolódnak? Vagy BCD-ben? Előjelesen vagy sem?)
Ezt azért pontosítsuk: negatív az a szám, amelynek az előjelet jelző bitje 1.
Ez pedig nem lehet a szám legmagasabb helyiértékű bitje, hiszen akkor honnan tudnád, hogy -2 vagy a 3. amit ábrázol.
Az előjelbit pedig a jobbról számított 8. bit (ami annyiban legmagasabb "helyiértékű", hogy nem előjeles ábrázolásnál ezen a biten van a legmagasabb hatványhoz tartozó érték).
Ugyanazt a számot tekintheted előjeles és előjel nélküli egésznek is. Maga az 11111111 nem egyértelmű, ha nem rendeltél típust hozzá. A legtöbb nyelv ismeri a "signed int" és "unsigned int" típusokat ugyanannyi biten (bár ez éppen C-s megnevezés). Viszont ha -1-nek tekinted, az bitszámtól függetlenül minden egész típusra jó lesz, ha meg előjel nélkülinek, az 8 biten 255, 16 biten 65535 stb. A -1 meg örök és megbonthatatlan. :-)
Előjeles: -128 - +127
Előjel nélküli: 0 - +255
stb. több biten is.
Egyébként az előző hozzászólásomban az az érdekes, hogy beírás közben jöttem rá magam is. :-)
Hm. Nem tudtam. Igaz, vba-ban sosem használtam. Viszont most esett le a tantusz, hogy retro image miért írt egy régi hozzászólásában valami ilyesmit: a=-(b=c) *d. Kösz.
Régi BASIC-es hagyomány az igaz értéket -1-nek venni. Ennek az az alapja, hogy ha egy byte-ot (szót stb.) feltöltünk csupa egyes bittel, akkor a kapott szám előjeles egészként -1-nek felel meg. Vagyis ez az a szám, amelyiknek minden bitje 1 (és így pl. a bitenkénti logikai műveletekben is feltétlenül igaz értékként viselkedik).
Az igaz viszont a munkalapon = 1, VBA-ban pedig = -1.
Próbáld ki a VBA-ban a True * 1 kifejezést. Eredmény: -1.
Csak nyilván, nagyon ritkán "számolunk" vele, inkább használjuk a logikai "értéket". Pedig, mint az adott példa mutatta, egyszerűbb is lehet a képlet esetenként, ha számnak tekintjük.
Apropos: Hogy-hogy nem ugyanaz a szám van rendelve az igaz/hamis-hoz a vba-ban és a munkalapon? Én idáig abban a hiszemben voltam, hogy a hozzárendelt számok mindkét helyen 1 és 0.
Meg lehet. De attól függően, hogy mik az érényesítés feltételei, lehet egyszerű vagy komplikált. Lehet, hogy simán alkalmazható az excel Adatok/érvényesítés parancsa, de lehet, hogy önmagában nem elég, és makrót kell az érvényesítéshez írni. Ezért első lépésben nézd át az említett parancsot, és ha az nem elég, akkor írd meg a konkrét előírásaidat.
Fferinek igaza lehet. De nem csak az excel nyelve lehet eltérő a két gépen, hanem a területi beállítások is. Írtam a korábbi hsz-emben, hogy hiába copy pasteltem be a Lin.ill súgó mintapéldáját, az én gépemen nem működött. Azóta rájöttem, hogy miért nem. Hát azért, mert a súgó példa magyarított példa volt, tizedesvesszővel. Én meg a saját gépemen tizedespontot használok. Így mintapélda tizedesvesszője miatt az excelem néhány számot stringnek értelmezett, amit a Lin.ill nem akceptál. Nos ilyen banális beállítási hibákra is vadásszál.
De hagy kérdezzem meg újra: hogyan kell a kitevőket kapcsos zárójelbe tenni?
Van egy kérdőív, ahol a válasz legördülő listából "igen" és "nem" lehet.
Értékelésnél adott válaszoknál az "igen" válasz érhet 1 vagy 2 pontot kérdéstől függően, a "nem" mindenhol 0 pontot ér.
Cél, a listából kiválasztott "igen" választásánál a kérdéshez tartozó 1 vagy 2 ponttal számoljon a táblázat, "nem"-nél 0 ponttal a mellette levő oszlopban.
Próbáltam képletek / definiált nevek / kijelölésből új opciót, ahol volt a listában
"igen" - "igen." - "nem" , Hozzárendelt számok 1-2-0.
Viszont, választás után mégsem tudta számként értelmezni a mellette levő eredmény oszlop.
Lehetséges ezt kivitelezni valahogyan?
A választ előre is köszönöm, képet csatoltam róla.
Ami az ékezetes változókat illeti én már beleütköztem a problémába. Idén egy bő fél éven át egy tagnyilvántartó programot írtam. Ez zömmel interaktív, amit userformokkal oldottam meg. Aztán amikor a program egy angol nyelvű office-t használó kollégám kezébe került, előjött, hogy nem fut a progam. Pontosabban Lost Visual Basic project hibát jelzett. És néhány nap kellett, míg kiderítettük, hogy a hibát a Userformok és a rajtuk elhelyezett ékezetes objektumok okozták. Ezeket néhány órás munkával kijavítottam, szerencsére a függvények és változók nevével nem volt gondja az Excelnek.
Szóval igazad van, és rossz szokásom, hogy használom a kódban az ékezeteket. Lám hová vezet a féktelen nacionalizmus:-))) Még szerencse, hogy nem rovásírást használtam:-)
Szóval ebben is egy nagy elhatározásra lenne szükségem, hogy ezentúl leszokjak az ékezetek használatáról a programkódokban.
Hogy még szebb legyen, egyáltalán nem kell aktívnak lennie a munkafüzetnek sem:
Az előzőekben leírtak akkor is működnek, ha a
Workbooks(wbnév).Activate
sort kihagyod.
Hiszen ws.parent.name = wbnév. (Azaz a ws munkalapod a wbnév nevű munkafüzetben van!)
Még egy tanács: én abszolut nem használom az ékezetes változókat, mivel nem hordozható. Nem tudhatod, hogy egy másik gépen milyen windows fut. Ha nem magyar, akkor az ékezetes, pláne a két pontos, vesszős betűk jól bekavarhatnak.
Ezt valóban nem tudtam. Egyébként amióta többen leírtátok, magam is kerülöm a select használatát, viszont tartományban történő keresésnél egyelőre nem tudom kiváltani:
Nagyon kevés az olyan művelet, amit csak select után lehet végrehajtani. Általában erre nincs szűkség, "üldözendő" jelenség a kódban. A makrórögzítő utáni kódból ezt kell legelőször kitakarítani. (Meg az olyanokat, mint scroll...)
