-
Fototrend
Új hozzászólás Aktív témák
-
zsolti_20
senior tag
Sziasztok! Az előző alkalommal is nagyon segítőkészek voltatok, tökéletesen működik amit elterveztem.
Sajnos van egy rész aminél elakadtam. Ez egy régebbi dolog már, de felbuzdulva a tegnapi dolgon, úgy gondoltam megkérdezlek titeket, hátha láttatok már hasonlót.
Szeretnék egy tickbox tickelni javascripttel, de úgy néz ki, hogy ennek a boxnak nincs azonosítója.
Annyit látok csak amikor megnézem mi van mögötte:Amikor tickelve van:
<td width="16px">
<img src="folder/folder/folder/folder/iconCheckAll.gif" align="absmiddle" style="width: 16px; height: 16px;">
</td>
Amikor nicns tickelve:
<td width="16px">
<img src="folder/folder/folder/folder/iconUnCheckAll.gif" align="absmiddle" style="width: 16px; height: 16px;">
</td>
Ha csak simán a .gif nevét írom át, betickeli,
de úgy veszi mintha semmi sem történt volna.
Még soha nem találkoztam ilyesmivel, ID hiányában hivatkozni sem lehetséges rá.
Valaki még régen azt mondta nekem, hogy ez egy DHTMLX. Nem tudom ez mennyit segít
a jelenlegi helyzetben.[ Szerkesztve ]
-
sztanozs
veterán
-
disy68
aktív tag
válasz zsolti_20 #16552 üzenetére
van bizonyára az elemen vagy valamelyik szülőjén egy eseménykezelő, ami feltételezhetően egy click hatására csinál valamit (sanszosan többről van szó, mint a képcsere)
böngésző dev-tools inspectnél meg lehet nézni, hogy min van milyen eseménykezelő (firefox-é sztem átláthatóbb e téren)
mondjuk az is lehet, hogy hiába találod meg ezt, ettől függetlenül nem biztos, hogy az értlemezése/használata triviális lesz
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
pmonitor
aktív tag
válasz pmonitor #16458 üzenetére
A FindFileC.exe programot frissítettem, valamint a forrása is megtalálható a .rar fájlban. A forráson még bőven lenne mit csiszolni, de működőképes. Ha valaki működést érintő bug-ot talál benne, akkor megköszönném, ha jelezné. Tényleg jó lenne, ha lenne egy ilyen win32-es topik, ami csak ilyenekkel foglalkozna. De ahhoz az kellene, hogy lenne több olyan, aki keni-vágja ezt a témát. Még az is lehet, hogy én is kérdeznék Pl. hogy miért nem működik az sprintf(...) win32-ben? "Error LNK2001 unresolved external symbol __imp____stdio_common_vsprintf" hibaüzit ad. Mindenesetre suszter módszerrel megoldottam a helyettesítését a FindFileC-ben.
------------------------------------------------------------------------
Egy másik téma egy olyan témakörből, ami lehet, hogy többször előjön nálam, mert engem eléggé irritál a(z) (erőforrás)pazarlás. Szóval a régi szép időben az IDE megvolt pár megából. Most a VS alsóhangon is 5-6 giga, de inkább 10-nél kezdődik(régebben egy egész winchi volt 2 giga körül!). Hová jutunk, ha ez a "fejlődés" így megy tovább? Az oké, hogy a VS többet tud, de azért mégis...
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
zsolti_20
senior tag
válasz disy68 #16554 üzenetére
Köszönöm a tippeket sztanozs és disy68. Sikerült kideríteni, hogy a kód az egér X és Y koordinátáját kéri le, majd ez alapján dönti el, hogy melyik tickbox .gif-et kell oda tennie.
Ez a megoldás működhet java scriptből, mert letudom kérni az egér X és Y koordinátáját, a probléma már csak az, ha legörgetek a weblapon akkor a tickbox X Y koordinátája és máshol fog elhelyezkedni.
Így ha megadok neki egy egér kattolás nem a megfelelő helyen fog megtörténni.<html>
<body>
<script>
onmousemove = function(e){
console.log("mouse location:", e.clientX, e.clientY);
var pos = e;
var dot;
dot = document.createElement('div');
dot.className = "dot";
dot.style.left = pos.x + "px";
dot.style.top = pos.y + "px";
document.body.appendChild(dot);
}
</script>
</body>
</html> -
opr
veterán
válasz zsolti_20 #16556 üzenetére
"a kód az egér X és Y koordinátáját kéri le, majd ez alapján dönti el, hogy melyik tickbox .gif-et kell oda tennie."
Uristen.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
-
Ispy
veterán
válasz pmonitor #16562 üzenetére
Nem, ez azt jelenti, hogy 10 GB semmi. Én nem sírom vissza azokat az időket, amikor 1.44-es floppyról kellett a kliensekre a frontendet telepíteni. Most meg 10 GB a neten is átjön 15 perc alatt. Ettől még nem kell szar programokat írni...
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
fatal`
titán
A programok is nagyságrenddel bonyolultabbak lettek. Nem rémlik, hogy 20 éve 8 giga rammal ellátott mobiltelefonokat kellett volna emulálni pl., vagy éppen konténerizálni. Ez is csak töredéke az azóta született igényeknek.
Biztos meg lehetne csinálni, hogy kevesebb erőforrást igényeljen az IDE (a jelenlegi funkcionalitással), a nagyobb kérdés, hogy ki fizetné ki ezért a felárat? Némi tárhely több nagyságrenddel olcsóbb, mint a munkabér és ez így is van rendjén.
-
pmonitor
aktív tag
válasz fatal` #16564 üzenetére
A mobilos példád igaz. De egy mobilba is soknak tartom az app-ok helyfoglalását. Éppen nemrég kérdezte tőlem egy idős néni, hogy az akcióban pár ezerért kapható 8 gigás tárhellyel rendelkező okostelót érdemes-e megvennie, mert Ő csak arra szeretné használni, hogy a tesco-ban az akciókat megnézze rajt. Mondtam Neki, hogy az sztem. nagyon kevés tárhely, mert az alkalmazások túl nagy helyet foglalnak.
De olyan aspektusa is van a dolognak, hogy hiába lett gyorsabb a HW, azért még mindig az a legszűkebb keresztmetszet. Így viszont hiába van 1 terrás HDD, azt mégsem lehet csak a VS-nek elfoglalnia. Méghozzá azért, mert így is egy közepes erősségű vason is nagyon lassan indul(főleg, ha töredezett a meghajtó).@dabadab: Gondolom azért, mert kevés komponenst telepítettél. Azért írtam, hogy alsóhangon 5-6 giga. 1-2 gigát tévedtem.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
dqdb
nagyúr
válasz pmonitor #16566 üzenetére
A fejlesztőeszköz munkaeszköz, így annyi helyet foglal, amennyit. A VS helyfoglalása amúgy is elveszik az X darab használt middleware, konténer, temp fájlok, checkoutolt Git repó között.
Így viszont hiába van 1 terrás HDD, azt mégsem lehet csak a VS-nek elfoglalnia. Méghozzá azért, mert így is egy közepes erősségű vason is nagyon lassan indul(főleg, ha töredezett a meghajtó).
Az a fejlesztő, aki HDD-re telepíti a VS-t, nagyon utálja magát, és már 10 évvel ezelőtt is nagyon utálta magát. Szerintem relatíve sosem volt még ilyen olcsó egy átlagos fejlesztésre/virtualizálásra kiválóan alkalmas gépet összeállítani az olcsó SSD és sokmagos processzorok korában.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
pmonitor
aktív tag
>A fejlesztőeszköz munkaeszköz
Mondjuk ezért nem értem pontosan, hogy ez miért off téma?>Az a fejlesztő, aki HDD-re telepíti a
Ez elírás volt. Bocsi. De a disk I/O így is a szűk keresztmetszet a RAM-al szemben.
Az én vasam egyébként 2019-ben volt a felső kategória alsó határán(nem mintha ez valamit is jelentene). De sosem voltam híve az erőforrás pazarlásnak. Talán ezért zavar engem ennyire.@Ispy #16568: nekem 250 giga partíció van a rendszernek, és ennek kb. a 35%-át használom.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
dabadab
titán
válasz pmonitor #16566 üzenetére
Gondolom azért, mert kevés komponenst telepítettél.
Igen, mert nem fejlesztek egyszerre harminc nyelven - ahogy egyébként kb. senki sem.
Amúgy meg azt a 4 GB teljesen érdektelen, maga a forráskód, amivel dolgozok, szintén akkora, ha meg még le is fordítom, akkor meg 60 GB.#16568 Ispy:
Én is csak azért tudom, mert most direkt megnéztem[ Szerkesztve ]
DRM is theft
-
pmonitor
aktív tag
válasz dabadab #16570 üzenetére
>Igen, mert nem fejlesztek egyszerre harminc nyelven
Én meg inkább programnyelvet sajátítok el minél többet(legalább közepes szinten), minthogy perfekt angol lenne a cél. Mások vagyunk. Mindenkinek más a "priori".
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
martonx
veterán
válasz pmonitor #16566 üzenetére
Viszonyításképpen nekem Ryzen 7 5800x-en, 1 TB-s X4 m.2-es SSD-n, úgy indul a VS, mint az álom. Hol lassú ez? Szvsz iszonyat gyors. És a build idők is röhejesen alacsonyak. Igaz töbnyire Microservice-ekkel, meg Web API-kkal foglalkozok.
Ja, és a telepítés kevesebb, mint 7 GB-t foglal.Én kérek elnézést!
-
fatal`
titán
válasz martonx #16573 üzenetére
Ja hát a microservice persze, hogy gyorsan buildel. Nyiss meg egy régi solution 150 projekttel aztán meglátjuk mennyire gyors.
Mondjuk általában a ram korlát és a rengeteg process a probléma, vélhetően ez a 22-es vs-sel megoldódik (még nem próbáltam). Meg aztán a R# is sokat lassít, bár azt nyilván nem használja mindenki.
[ Szerkesztve ]
-
pmonitor
aktív tag
válasz Fire/SOUL/CD #16427 üzenetére
Még azt mondják, hogy nem lehet assemblyvel gyorsabb kódot írni! Az olyanoknak ajánlom ezt a példakódot a figyelmébe:
#pragma once
#define _CRT_SECURE_NO_WARNINGS
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <sys/timeb.h>
int int_ToString(int num, char* dest);
char str[12];
long timediff(struct timeb* start, struct timeb* end)
{
long seconds;
seconds = (long)(end->time - start->time);
start->millitm = end->millitm - start->millitm;
if (0 > start->millitm) {
start->millitm += 1000;
seconds--;
}
return seconds;
}
int main(void)
{
struct timeb start, end;
long seconds, seconds_1;
int militm, militm_1;
int i;
ftime(&start);
for (i = 0; i < 100000000; i++)
{
sprintf(str, "%d", -2138);
//printf(str);
}
ftime(&end);
seconds = timediff(&start, &end);
militm = start.millitm;
ftime(&start);
for (i = 0; i < 100000000; i++)
{
int_ToString(-2138, str);
//printf(str);
}
ftime(&end);
seconds_1 = timediff(&start, &end);
militm_1 = start.millitm;
printf("Eltelt ido(sprintf()): %ld.%03d masodperc\n", seconds, militm);
printf("Eltelt ido(assembly): %ld.%03d masodperc\n", seconds_1, militm_1);
}
int int_ToString(int num, char* dest)
{
__asm
{
mov edi, dest
mov eax, num
xor edx, edx
cmp eax, edx
jge nemnegativ
mov ecx, -1
imul ecx
push eax
mov eax, '-'
stosb
pop eax
nemnegativ :
xor ebx, ebx
push_chars :
xor edx, edx
mov ecx, 10
div ecx
add edx, 0x30
push edx
inc ebx
test eax, eax
jnz push_chars
pop_chars :
pop eax
stosb
dec ebx
cmp ebx, 0
jg pop_chars
mov eax, 0x0a
stosb
}
}Nálam itt az sprintf(...) stabilan 6 sec felett, az assembly kód stabilan 2 sec. alatt teljesített. Csupán kevesebb, mint az egyharmada alatt fut le az ASM kód.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
pmonitor
aktív tag
válasz Silεncε #16576 üzenetére
Idézet Innen:
Nem azt mondom, hogy lehetetlen gyorsabb assembly kódot írni, mint amit egy C fordító gyárt, csak azt, hogy nagyon nehéz, és az is csak valamivel lesz gyorsabb, de messze nem a "min. 15 éves gépeken is pont úgy menne egy mai/2021-es játék, mint a mai erőműveken" kategória lesz.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
dabadab
titán
válasz pmonitor #16575 üzenetére
Nálam itt az sprintf(...) stabilan 6 sec felett, az assembly kód stabilan 2 sec. alatt teljesített.
Mert nem ugyanazt csinálták: az sprintf() egy elég nagy tudású, rugalmas függvény, a te assembly kódod meg csak 32 bites inteket tud kiírni mindenféle formázás nélkül. Nyilván ha ugyanezt megírod C-ben, az is gyorsabb lesz, mint az sprintf, vagy ha az sprintf()-et megírod assemblyben, az meg minden bizonnyal lassabb lesz, mint az, ami a gyári stdlibben van (az alapján, hogy a mostani assembly kódod is elég szuboptimális).
Sőt, itt van C-ben egy még gyorsabb megoldás, ami a te assembly kódoddal ellentétben még csak nem is bugos
int int_ToString(int num, char* dest) {
memcpy(dest, "-2138\n", 7);
}[ Szerkesztve ]
DRM is theft
-
pmonitor
aktív tag
A ciklus módosításával:
for (i = 0; i < 1000000000; i++)
{
//sprintf(str, "%d", -2138);
itoa(-2138, str, 10);
//printf(str);
}Itt egy 0-t tettem a végére, úgyhogy azt a másik ciklusba is oda kell tenni. Így az itoa() kb. 22 sec., az int_ToString() kb. 14 sec. alatt fut le. Ez már lényegesen jobb, de azért egyértelműen gyorsabb ennél is az asm.
@dabadab:
>mondjuk lehet, hogy azért így is megverné ezt az assembly kódotNem haragszom meg, ha csinálsz jobb asm kódot.
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
Marky18
aktív tag
válasz fatal` #16574 üzenetére
Sokkal gyorsabb a 22-es. Most fejlesztettem egy kozepes meretu solutionbol allo .NET Core appot es volt idom parhuzamosan probalgatni a 19-es es a 22-es VS-t. Minden teren (startup, build, debug) sokkal gyorsabb az uj, igaz most mar be is foglalja a memoriat. De legalabb gyors
Az intelligens kodkiegeszites pedig baromi jo, rengeteg boilerplatet meg lehet iratni egy tab-al. -
fatal`
titán
válasz Marky18 #16588 üzenetére
"sokkal gyorsabb az uj, igaz most mar be is foglalja a memoriat."
Az nem probléma, azért van (mármint a RAM).Viszont ismerősöktől azt hallom, hogy még elég bugos.
"Az intelligens kodkiegeszites pedig baromi jo, rengeteg boilerplatet meg lehet iratni egy tab-al."
Én az a ritka faj vagyok, aki nem nagyon generál kódot, valószínű, mert rohadt gyorsan gépelek így nem zavar. Sokszor hülyeségeket ajánl, bár lehet, hogy mostanra már jobb a helyzet.Lassan legalább itthon fel kéne tennem a 22-est megnézni. Bár itt meg nincs méretes projekt.
-
dqdb
nagyúr
válasz Marky18 #16588 üzenetére
VSIX-et nem telepítettél rá (esetleg fordítottál) véletlenül? Számomra a VS egyik legnagyobb rejtélye, hogy mi tart hosszú percekig egy apró extension telepítésén (ami persze az extension fejlesztése/tesztelése közben még fájdalmasabb tud lenni).
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
Ispy
veterán
Esetleg ha valaki hasznáná a built in sql tools (compare) az új vs-be kiváncsi lennék rá, mert a 2019-ben elég lepra a sebessége sajnos, pedig jó vóna.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
pmonitor
aktív tag
válasz pmonitor #16585 üzenetére
Az ittenke lévő kódom már tudja a bináris, oktális, és a hexadecimális számrendszer kiírását is. Ugyanakkor még így is jóval gyorsabb, mint az itoa(...)
Hát hiába, az ASM nem hazudik! Főleg, ha egy olyan tud hatékonyabb kódot írni az enyémnél, aki keni-vágja a témát. Mert nekem össze kellett szednem magam, hogy ezt kiizzadjam magamból.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
ReSeTer
senior tag
Helló!
Melyik nyelvet érdemes választanom, ha ipari cégnél szeretnék kisebb programot írni, többnyire CAD és egyéb program egymással való kommunikáció kiépítése céljából, vagy egyszerűbb munkafolymatot segítő programot (üzemnek rajz leadása rajta keresztül, mindig tudják, hogy melyik a legfrissebb, le tudják tölteni stb..., termék státuszkövetés)
Én C#-re gondoltam, C++ semmiképp, nem akarok olyan szinten belemászni.
Esetleg valami más, ami működhet könnyedén Windowsos környezetben?[ Szerkesztve ]
-
opr
veterán
válasz ReSeTer #16598 üzenetére
"többnyire CAD és egyéb program egymással való kommunikáció kiépítése céljából"
Ha itt konkrétan pluginról van szó, akkor meg kell nézni, hogy a konkrét programoknál ez hogy működik, milyen nyelv támogatott, és azt."üzemnek rajz leadása rajta keresztül, mindig tudják, hogy melyik a legfrissebb, le tudják tölteni stb..., termék státuszkövetés"
Erre lehet azt mondanám, hogy Python. Ennyit bőven simán tud, egyszerű, platformfüggetlen... Mi kell még?"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
dabadab
titán
válasz ReSeTer #16598 üzenetére
Igazából ilyen feladatoknál szerintem érdemes körbenézni, hogy van-e valami létező program, amit lehet használni erre a célra, ahelyett, hogy te magad írnál valamit.
Amúgy meg ha tényleg kicsi meg tényleg meg kell írni, akkor inkább Pythont néznék, az tök jó ilyesmire.
[ Szerkesztve ]
DRM is theft
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Újabb Samsungok telepíthetik a Galaxy AI-t
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- Mindent megtudtunk az új Nokia 3210-ről
- Kerékpárosok, bringások ide!
- Milyen billentyűzetet vegyek?
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- nVidia tulajok OFF topikja
- Vezetékes FÜLhallgatók
- Léghűtés topik
- Érkezik Magyarországa az LG szuper dizájnos hordozható projektora
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest