Üdv! Az alábbi problémát az élet hozta. Leírnám a részleteket hogy érthető legyen mit is akarok.
Nyomógombos, számkódos ajtózáraknál ahol nem változtatják a kódot időnként, látszik a lekopott gombokról, hogy nagyjából miket kell nyomkodni. Na most ha mondjuk vegyük 4 helyiértékes a kód, és 1 számjegy van felhasználva értelemszerűen 1 gomb lesz lekopva és abból adódik a variációk száma összesen: 1 (1111) Ha 2 számjegyet használunk fel ui. 4 helyiértéknél, akkor lehet pl.: 1112 1121 1211 2111
1222 2122 2212 2221
1122 1212 1221 2112 2121 2211
Ez 14 lehetséges variáció 2db kopott gombon. 3 számjegy felhasználásánál 36, 4-nél 24 variáció adódik (nem írom le).
Viszont kéne nekem egy JS kód ami ezeket ilyen mód előállítja elkülönülően egy html-be pl. tetszóleges helyiértékek esetén amit egy form-ban meg tudnék előre adni. Próbáltam gondolkodni hogy lehetne ezt algoritmizálni while ciklusokkal, tömbökkel, tervezgettem papíron ahogy régen szokás volt, de nem sok ötletem maradt hogy ezt milyen programozási technikával lehetne JS-en belül jól megoldani. Tudnátok esetleg ötleteket adni? Köszi!
Ismeri valaki az arbor.js-t? Esetleg GraphViz-t? Php/MySQL-ből kellene kapcsolati hálókat rajzolnom, ehhez hasonlót. Tudna segíteni valaki a megvalósításban?
1: A demó oldal forrását nézve nem találom a helyet, ahol elindítja a js scriptet. Ez hol történik meg?
2: Ha a jobboldali textarea-ban módosítok egy "pont -> pont" párt, kb. 1mp-cel később módosul a graph. De ezt hogy éri el? Az oldal forráskódjában üres a textarea.
3: A HALFVIZ feliratra (about) kattintva azt írja, hogy a régi .dot grafikon-leíró nyelvre alapozott halftone nyelven lehet megadni a pontokat, de a doksiban nem írja le ennek a módját, csak a közvetlen (programozott) megadást: sys.addEdge('a','b'). Vagy ti látjátok?
Esetleg tudtok egy jobb megoldást kapcsolati hálók megjelenítésére?
Hmm, hülye vagyok, a gombok kattintása valószínűleg eleve elveszi a fókuszt, ezzel így ebben a formában tehát nincs mit kezdeni. Az persze még érdekel, hogy miért nem villog a kurzor az event után.
else if (ofThisInput.selectionStart || ofThisInput.selectionStart == '0') {
theCursorLocation = ofThisInput.selectionStart;
}
return theCursorLocation;
}
var currentPos = theCursorPosition(theIdElement);
var origValue = theIdElement.value;
var newValue = origValue.substr(0, currentPos) + thisChar + origValue.substr(currentPos);
theIdElement.value = newValue;
document.getElementById(theIdElement).focus();
}
Tulajdonképpen működik, speciális karaktereket szúr be input mezőbe. A baj az, hogy nem jól kezeli a focus()-t. Az if (document.selection) résznél(?) elmászik.
Nem csak arról van szó, hogy szeretném a kurzort villogva látni, de van egy onBlur() eseményem ami ilyenkor mindig lefut (pedig nem kéne). Itt van a dolog gyakorlatban.
Így utólag belegondolva akkor az lehetett a te problémád, hogy a scripted előrébb volt, mint a babrálandó HTML elementek, így amikor a $('#qnEditForm')-ot hívtad, akkor az még nem volt meg, ezért nem találta. Így viszont még alternatív megoldásnak lehetett volna kisérletezni a script tag defer tulajdonságával is.
Köszönöm, megoldódott (thanks MerlinW@sg). Az egész $(document).ready()-be csomagolva máris működik.
$(document).ready(function() { $("#qnEditForm").change(function(){ var mand = $("input[name='mand']:checked").val(); if ( mand == 'y' ){ alert ( mand ); } }); });
Aztán leesett, hogy id nélkül macerás a másik radio-t visszakapcsolni, úgyhogy lett id, amivel sokkal egyszerűbb kódot lehet írni, itt a végső változat:
$(document).ready(function() { $('#mand1').change(function(){ // ha rákattint az igenre if ( !confirm ( 'Biztos vagy benne?' )){ // visszakérdezünk $('#mand2').prop('checked', 'checked' ); // ha nemet mond, visszaélesítjük a nemet } }); });
'reggelt! Ez miért nem működik, és hogy tudna mégis?
$('#qnEditForm').change(function(){ var mand = $('input[name=mand]:checked').val();
if ( mand == 'y' ){ alert ( mand );
} });
Van egy input type=radio, benne két option name=mand, az egyiknél value="n", a másiknál "y". Azt szeretném, hogy ha valaki az "y"-t választja, dobjon fel egy confirm-öt, hogy biztos akarja-e.
A rádióknak nincs saját ID-jük. Van nevük, de hiába írom úgy a kódot, hogy $(input[type=radio]) vagy $(input[name=mand]), change-re semmi sem történik, hibaüzenet sincs. Ha azt írom, hogy $(document).ready(...), akkor megvan az érték, de azzal nem sokra megyek, nekem a változtatáskori kell.
Az alert ( mand ) csak tesztből van ott, a confirm résszel még elboldogulok.
Sziasztok, látom nem nagyon aktíva fórum, de lenne újabb kérdésem.
Javascripttel/Jquery-vel (vagy ha tudtok jó libraryt, nekem az is jó) szeretnék mozgatni egy tárgyat a képernyőn a
szimpla WSAD billentyűkombinációkkal (ha lenyomom, akkor menjen, ha nem nyomom akkor ne menjen). Nyilván vannak a keydown keyup eventek, amikre szépen fel lehet iratkozni, de a probléma csak ezután jelentkezik.
Van az a windows-os jelenség, hogy ha leütünk egy billentyűt, akkor utána vár egy kicsit, és csak utána veszi be a leütést
sorozatosan egymás után. Ebből kifolyólag az elemem először egy kicsit megindul, vár, és utána kezd csak el az adott irányba
elmozdulni. Azt szeretném elintézni, hogy ha lenyomom a D-t akkor menjen jobbra, szépen rendesen ahogy kell neki.
amikkel eddig próbálkoztam:
-Jelenleg nem csinálok mást, csak a margin-left-jét növelem, ha keydown-t érzékel.
-A Position függvény nem jött be, mert azzal nem tudom elintézni, hogy simán menjen jobbra, az gyorsít, lassít,
szakaszosan veszi be az inputot stb (vagyis ugyanez a probléma ott is fennáll).
Ha persze be lehet ezt rendesen konfigurálni, hogy úgy működjön ahogy én akarom, az király lenne.
- Megpróbáltam, hogy setinterval-al csinálok egy végtelen ciklust, (setinterval nélkül si próbáltam magában az eseményben), ami ha érzékeli a rightDown globális változón, hogy true, akkor fut, ha nem true, akkor nem fut (a változó állítását nyilván a keydown, keyup eseményekkor állítom). A probléma a végtelen ciklusos megoldással az (azon felül hogy erőforrásigényes), hogy valamiért nem rajzolja
ki on the fly a képernyőre az eredményt, de ha beledebuggolok a végtelen ciklusba, akkor látom, hogy kiteszi (mintha nem lenne ideje
kirajzolni, mert időközben változik az értéke)--> (bár ezt cáfolja, hogy amikor a setintervalt 2 mp-re raktam, akkor se rajzolta).
Ha van valamilyen elfogadott kliensoldali módszer erre, légyszi segítsetek, mert tényleg sok időt belefeccöltem.
ui.: igyekszem kerülni a nagyon elborult javascript library-kat, mert csak a mozgatás miatt nem akarok behívni egy egész libraryt. (persze ha nincs más megoldás, akkor nyilván az is jó).
Ha a body végére szúrod, akkor majdnem az egész dom fát látod jsből. Amit nem látsz, azt valószínűleg nem is akarod látni, mert nem véletlenül tetted be a script taged után. Itt a body lezárója nem számít, mert már létezik a body element. De a defer még mindig a barátod. Minden másra ott a window objektum onload eseménye. Az viszont tényleg csak akkor fut le, ha már az egész dom fa felépült.
Ilyen a popszakma, egy csomó egyéb más sem szemet gyönyörködtető, de ennek az iparnak is megvan a saját a szigszalagja és wd40-e és elég gyakran is használják. Ha nem tetszik a záró body tag elé beszórt scriptek, akkor valóban, jó barát lehet a defer, de még a window onload eseménye is, az meg még lehet hogy TypeScripten keresztül is működne ellenben a jQueryvel. Tkp a jQuery ready függvénye is ugyanez, csak pepitában.
Zavart érzek az erőben: Szinkront írsz, majd leírod milyen az aszinkron. :)
A setTimeout és a setInterval is pont aszinkron, tehát az a helyes, ahogy leírtad. Meg a JS-ben jópár dolog aszinkron: eseménykezelés, XmlHttpRequest, setTimeout, stb-stb. Amiket írtál kódrészletek viszont egyik sem, tehát azokban szép sorban futnak le az utasítások.
Na szerintem ez ma már 10 eszközből 10-en lefut, de egy kis akadás az op. rendszerben meglátásom szerint meghiúsíthatja a dolgot. Én legalábbis úgy tudom, hogy a JavaScript eléggé szinkron működésű ebben a tekintetben, azaz ahogy megy sorban a kódon, a document.body-s résznél a böngészőnek átadja a sztringet, ami már elegendő számára a tovább lépéshez. A böngésző meg majd valamikor beilleszti ezt a DOM-ba, de ennek nyugtázása szerintem elmarad a JS futása során. Hasonló, bár nem igazán jó példa, hogy miért nem lehet egyszerűen felfüggeszteni a JS futást: a setTimeout()-ot követő sor nem akkor jön, amikor lejár a setTimeout, hanem azonnal, ahogy létrejött a setTimeout referenciája.
Gyakorlatilag tehát ez tisztázandó, hogy a JS futás függ-e a DOM műveletektől, vagy sem.
(Hasonló példa lehet, ha egy képnek relatív méretet adsz JS-ben, majd következő sorban lekérdezed a fizikai méretet. Szerintem itt is csak a mostani agyon optimalizált gépeknek köszönhető, ha van eredmény:
kep.style.height = "90%";
console.log(kep.offsetWidth);
Szerintem itt ugyanaz történik, mint fent: a JS átadta a style property-t, ezzel végzett az adott kódsorral, jöhet a következő. A böngészőnek azonban idő, pláne egy nagyfelbontású képnél, hogy értelmezze először ezt a 90%-ot, másodszor pedig azt, hogy mi történik a szélességgel a képarány tartása miatt. Így rögtön utána fizikai méretet kérdezni JS-ben szerintem hiba, könnyedén előfordulhat, hogy még az előző méretet fogja visszaadni, ami még a 90%-os magasság előtt létezett.)
"Hogy objektív választ adjak: attól még, hogy nem a HEAD-ben, hanem a legvégén van a szkript, még nem jelenti azt, hogy áll a DOM, mikor az lefut."
Az egész DOM akkor még nem, de az a része, ami kell a kérdezőnek, az már igen. Aztán lehet hogy egy plusz szuper hátéemelötös async tulajdonság okozta a zavart az erőben odaát. Jópár hónapot lehúztam egy egész nagy forgalmú webes szolgáltatás patkolásával, de ilyen hibába nem futottam bele, pedig fogtam ám ki cifra dolgokat. Mindennek ellenére nem tartom kizártnak hogy én tévedek, de szvsz elég kicsi az esélye.
Alapvető tévút. Az, hogy elsőre működik, a szerencsének köszönhető. A szerencse a mai gépeken persze ott lesz még melletted sokáig, de mi van, ha nem?
Hogy objektív választ adjak: attól még, hogy nem a HEAD-ben, hanem a legvégén van a szkript, még nem jelenti azt, hogy áll a DOM, mikor az lefut. Egy lassabb gép, vagy egy gyors gép terheltebb pillanatában előfordulhat, hogy még nem állt fel a DOM, a szkript viszont már futna. Ez ugyanis nem szinkron futású, hasonló a helyzet, amikor JavaScript-tel hozol létre egy új elemet, de nem objektumként, hanem HTML forrásként adod hozzá a szülő elemhez. Ha rögtön utána hivatkozol rá immáron DOM azonosítóval, az esetek többségében működni fog, mivel a mai eszközök kellően gyorsan beillesztik a DOM-ba, gyorsabban, mint hogy a következő parancs fussék a JS sorban. De ezt semmi nem garantálja, így nem lesz megbízható a kód futása.
Ha a megbízhatóság Nálad nem szempont (mert ez is előfordulhat), akkor semmi akadálya a jelenlegi megoldásodnak. Egyébként viszont érdemes lenne megtalálni az okát, hogy a document.readyben a Typescript miért nem működik megfelelően.
Úgy kellene használnom a Jquery-t (most mindegy, hogy miért), hogy nem a document.ready-n belül futtatom a lekérdezéseket, hanem anélkül. Most elvileg ugye azért van szükség a document.ready-re mert ha
a <head>-ben én behívom a javascript fájlomat, akkor ugye még nincs felépülve a DOM fa a háttérben, és
semmit se fogok abból megtaláni.
Na most mi van akkor ha én nem a head-ben hívom be a javascript referenciát, hanem az aspx
legalján, mielőtt bezárnám a <body> tag-et. Ott már ugye betöltődtek a szükséges html elementek.
A dolog működik első futásra, nem is ez a kérdésem lényege, hanem hogy láttok e bármilyen komplikációt a jövőre
nézve, ami előfordulhat ha ezt az utat választom? Mondjuk generálhat e még később az asp.net valamit amire nekem esetleg
szükségem lehet?
ui.: Amennyiben fontos lenne a dolog miértje leírom; Typescriptet és jquery-t használok egybeolvasztva, csak
a typescript nem generálja le a class-okat (meg egyebeket), ha a document.ready-be teszem őket.
Ha hagyományos módon a <head>-ben referálom be a js fájlomat, akkor minden hívásnál, ahol meghívom a typescriptes objektumaimat, szükségem van egy document.ready-re ami rondítja a kódot. Azonban ha a dom végén referálom be, akkor
