bubu

Pirmkārt - sāc ar sakarīgāku topika nosaukuma izdomāšanu. Esošais ir pārkāpj foruma noteikumus. Un otrkārt - atbilde ir meklējama izceltajā topikā, šajā pat foruma sadaļā: http://php.lv/f/topic/7294-headers-already-sent/

Ko nozīmē - "rediģējas visi lauki"? Tas jau nav svarīgi kā saucas lauki, tiem tu visiem arī tagad tiec klāt: echo $_POST["vards_1"], "\n", $_POST["vards_2"], "\n", $_POST["vards_3"], "\n";

Kas tas ir - "tur kur ir visi tipi" ? Reku tev iedevu linku no MySQL dokumentācijas, kur ir visi datu tipi, kurus tas saprot. Un tur ir NUMERIC (aka DECIMAL).

Nu, nu.. 4NF ir jau daudz par traku. Vairums veidotās DB nav pat 3NF, kur nu vēl 4NF. Un tās strādā un funkionē visai normāli. Pirmās divas NF gan der ievērot (ar trešo jāskatās saprāta robežās).

Vai tu saproti, ka tajā str stringā tu meklē stringu "searchWhat.toString()", nevis čaru "n" ? T.i, tas tiks atrast tikai tad, ja str saturēs kautko šādu "asdfgsfg searchWhat.toString() zummdumm".

Kā tas ir - "tev nav" ? MySQL dokumentācijā gan ir: http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html

laacz'iz saka, ka tagad visam vajadzētu būt ok. Pamēģiniet, tiem kas lietot to mini operu. 08:40:39 <@lcc> bubu, ir taa, ka mees pashi neko neblokjeejam 08:40:52 <@lcc> ir bijushas suudziibas, bet mums nekaadi filtri nestaav 08:43:46 <@lcc> blja 08:43:51 <@lcc> vispar jau atradu gljuku gan 08:43:56 * lcc nebija apdeitojis bogon netus 08:43:58 <@lcc> labu laiku 08:46:32 <@lcc> nu gan vajadzeetu buut ok

Naudai (un citām mērvienībām, kurai ciparu precizitāte aiz komata ir svarīga) - NUMERIC Citiem (performances vajadzībām) - FLOAT vai DOUBLE.

Nevis vienādos, bet unikālos izmērus, pareizi? Ja tā, tad ej ciklā cauri un liec atrastos izmērus jaunā masīvā, pirms tam pārbaudod vai tie tur jau nav ielikti. Beigās arī dabūsi masīvu ar unikālajiem izmēriem.

Tad tas nav strings. Ja tas būtu strings, tad rādītos teksts "string" (bez pēdiņām). Un vispārīgā gadījumā object tipa instancēm nav tādas replace metodes. Skaties uzmanīgāk, ko esi padevis argumentā.

Javskriptā nav aizliegts rakstīt sekojoši: var string = 123; alert(string); Viss strādās. Problēma visdrīzāk ir tur, kur izsauc Utf8Encode funkciju. Vai tu tai argumentā tiešām padod tādu objektu, kuram ir replace metode? Pamēģini ielikt pirms 87. rindiņas sekojošu kodu: alert(typeof(string));

Nav ne jausmas. Pavaicā oficiālājā IPB supporta forumā. Tur noteikti kāds zinās. P.S. piedomā pie sakarīgāka topika nosaukuma.

Pieņemu, ka uzspiežot linku "Hide Debug Information", tas zemāk esošais pazudīs/aizvērsies. P.S. piedomā pie sakarīgāka topika nosaukuma un apraksta ("kr4" nav normāls vārds).

Tieši tāpat kā php: $arr = array(); for (...) { $arr2 = array(); $arr2[] = "..."; $arr2[] = "..."; $arr[] = $arr2; } tāpat dari arī JS (vai jebkurā citā programmēšanas valodā): var arr = []; for (...) { var arr2 = []; arr2.push("..."); arr2.push("..."); // vai arī abas iepriekšējās rindas var uzrakstīt vienā: // arr2.push("...", "..."); arr.push(arr2); } Nesaprotu par to tavu dublikātu veidošanu. Ja negribi dublikātus, tad pirms tam pārbaudi ir jau vai nav tur tāds iekšā (tam gan labāk izmantot asociatīvo masīvu, nevis lineāri skriet visiem ierakstiem cauri). Un ja ir, tad neliec vēl vienu rindu. Kur problēma?

Un kā tas "nesaprotami" izskatās vai izpaužās? Masīva izveidošana izskatās daudzmaz korekti. Tik dīvaini, ka tu aizpildi i-to indeksu, jo atkarībā no if nosacījumiem sanāk, ka masīvā tev var būt tukšas rindas (tiem kuriem, piemēram, Detail.IsComplexEdging ir true). Bet ja nu tā vajag, tad vajag. Es gan tā vietā būtu lietojis push metodi.

Sekojot līdzi IPB jaunumiem - jaunākām versijām, kas droši vien ietver koda drošības uzlabojumus.

Varbūt kautko labu izvada print_r($_GLOBALS) ? tev tur firame vieta jābūt iframe. Action atribūtā ir pareizi, ka absolūtais URLis lietots, pie tam localhost?

Un ko saka uz alert(form.getElementsByName("buffer_size")[0]); ?

Kāpēc global? Taisi to $db1 par memberu tai klasei, kura darbojās ar taviem datiem. Tu taču darības ar datiem neesi izmētājis pa visu skriptu no augšas līdz apakšai, ne? (tas nav ne ērti pārredzami, ne viegli uzturami).

Lielisks piemērs kāpēc singletoni ir slikti. Risinājums ir neizmantot singletonus: $db1 = new DB("aaa"); $db2 = new DB("bbb"); $db1->query(...); $db2->query(...);

Speciāli izcelts topiks šajā sadaļā: http://php.lv/f/topic/7294-headers-already-sent/ Lasi to.

Ja godīgi, neko nesapratu kas un kā tev jāpārveido... Bet par 2d masīvu - tev jau tas tika parādīts šeit: http://php.lv/f/topic/14187-jscript-masiva-izveidosana-kuru-var-papildinat/page__view__findpost__p__110154

Es taču, jau parādīju, kā var papildināt:

Tas joprojām nepastāsta pēc kādiem principiem tu uzstādi tās details[..] vērtības no abiem inscriptioniem.

Kautkas tev tomēr tu nesakrīt labi. Ja topEdge ir 0 un bottomEdge arī ir 0. Tad pēc pirmā case 0 sanāk, ka details[i][2] = "2"; details[i][3] = " "; Taču pēc switch'a default vērtības sanāk ka arī if(topEdge.Inscription == "0" || bottomEdge.Inscription == "0") ir true, un details[i][2] = "1"; details[i][3] = " "; (kurš protams nekad neizpildīsies, jo būs jau augšējais case izpildījies). Manuprāt tu tur kautko esi saputrojies. Tie if'i nekorekti izskatās. Kā jau saku - pastāsti labāk cilvēciskā valodā, pēc kādiem principiem tās vērtības tur saliekās.