Maris-S
-
Posts
634 -
Joined
-
Last visited
Everything posted by Maris-S
-
Kaut kas neiedomājams, ja kaut kas nestrādās ar css, tad tas pilnīgi noteikti būs ēzelī! Problēma rodas ja absolūti pozicionētā div tiek ielikti relatīvi pozicionēti. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Positioning</title> </head> <body> <div style="position: absolute; top: 50px; left: 100px"> <div style="height: 20px; background: blue; color: white"> Caption </div> <div style="width: 500px; height: 300px; background: lime"> Content. </div> </div> </body> </html> Mozillā parāda tā kā tam vajadzētu būt, satura sadaļa pastiepj visu konteinera divu, līdz ar to virsraksta rindiņa pastiepjas, kā arī vajadzētu būt relatīvi pozicionētam div, viņam jāpastiepjas 100% platumā, bet IE viņš nepastiepjas. Varbūt kāds ir atrisinājis šādu problēmu. Pa google tā arī nesanāca atrast risinājumu.
-
Tāpēc ka izmantojot return funkcija atgriež vērtību un pārtrauc funkcijas darbību. Izveido funkcijā mainīgo, tad pa ciklu veido izvadāmo tekstu un tikai tad return $mainigais. function funkcija() { $cells=''; for ($i=0; $i<2; $i++) $cells.=' <tr><td> Piemeers </td></tr>'; return $cells; } Kaut kā tā..
-
Njā, sākumā nepievērsu uzmanību, bet izskatās ka piemērā uz ko norāda Jamesona iemestais links menu platums ir mazliet lielāks par lapus satura lauku.. Varētu norādīt tā paša konteinera platumu atbilstošu, bet tas var radīt problēmas ja teiksim pastāv iespēja ka lapai menu lauciņu izmēri var mainīties, piemēram dažādu valodu pārslēgšanās rezultātā. Kaut gan pēc piemēra neizskatās ka menu lauciņu izmēri nebūs iepriekš zināmi.
-
Norādot marginu pilnīgi noteikti radīsies problēmas ar dažādām izšķirtspējām ja pārējo saturu centrē.
-
Tev šis meņu parādās tā kā tam būtu jāparādās šādā gadījumā. Lieta ir tā ka menu elementiem tiek izmantota css vērtība 'float: left' (peldošo objektu struktūra), tāpēc arī viņi izlīdzinās pa kreisi, ja lapas izmēri samazināsies, tad viņi sāks izkārtoties viens zem otra. Šajā gadījumā risinājuma variants varētu būt sekojošs: izveido div kas būs kā konteineris menu, šim div uzliec platumu kāds ir lapas satura platums (pieļauju ka jābūt tādam kā tā vidējā baltā daļa) un tad arī centrē to konteineri, bet menu liec viņā iekšā.
-
Starp img un inputu Tev būs atstarpes tāpēc ka Tu viņus saraksti jaunā rindā, htmlā jaunas rindas šajā gadījumā attēlojās ar atstarpi, vai nu mēģini visus trīs elementus koda rakstīt vienā čupā vai arī izmanto css 'float: left', nu un tur tad visu pārējo pēc vajadzības, pozicionēšanu, marginus un tml.
-
Mozillas lapā ir gan parastie css apraksti, gan arī mozillas paplašinātie css. Par to [type=submit], tā ir CSS3 iespēja, man šķiet ka IE7 jau sāk atbalstīt CSS 3, vismaz daļēji un šis variant uz IE7 strādā. Man te pašam ir tāds izveidots: input[type="submit"], input[type="button"] { width: 70px; height: 18px; font-weight: bold; padding: 1px; padding-right: 3px !important; padding-left: 3px !important; background-color: #E3EAF8; color:#444444; } Neesmu vēl saņēmies pārveidot, savādāk uz IE6 nav kā vajag.
-
Pseidotags hover patiešām nestrādās uz IE, no laika gala nav strādājis, kaut gan par 7. versiju neesmu pārliecināts. Šis pseidotags IE darbojas tikai uz <a> tagu, tāpēc visur citur ja vajag hover efektu iegūt ir jāizmanto javascripts. Tomēr pogām ir variants izmantot arī citu iespēju, proti izmantot tos pašus <a>, css vērtībai display piešķirot 'block', protams tad arī garumi, platumi, margini utt. jāpiešķir atbilstoši.
-
Par doctype nenorādīšanu nepiekrītu, to vajadzētu norādīt. Man pavisam nesen tādēļ radās problēma un tieši IE (7. versija) bez viņa nestrādāja pareizi. Problēma radās ar modālā lodziņa veidošanu (pa visu lapu puscaurspīdīgs div virsū pilnīgi visam un lodziņš virs puscaurspīdīgā div). Sanāca tā ka vecai lapai uzliku to lodziņu, sākumā pat nepaskatījos kas sanāk IE, pēc laika atklājās ka puscaurspīdīgais div pilnīgi uz leju aiz visa lapas satura, Sīki to lietu nepētīju, bet aizdomas ka nepareizi strādāja position:fixed css vērrtība. Tāpēc domāju ka šajā gadījumā doctype norādīšana darīja to ko tam būtu jādara. Ja tagad sāksies brīnumi ka dažreiz IE būs jānorāda tas doctype dažreiz nē, lūk tā gan būs problēma!
-
Pieļauju ka to datumu ir domāts glabāt datubāzē, tad vēl variants būtu mysql funkcija UNIX_TIMESTAMP
-
Bubu, paldies par linkiem, pašam nesanāca neko strādājošu atrast, skatīšos pēc Tavējiem...
-
Kārtējo reizi problēma ir IE, ja tiek padots lejupielādei fails ar unicode simboliem (piemēram, krievu valodā), tad IE faila nosaukumu pārveido ar ķeburiem, mozilla bāzētos pārlūkos un operā viss normāli. Headeri ko es izmantoju ir sekojoši: $mm_type='application/octet-stream'; header('Content-type: application/force-download'); header('Cache-Control: public, must-revalidate'); header('Pragma: hack'); header('Content-Type: '.$mm_type); header('Content-Length: '.$file_size); header('Content-Disposition: attachment; filename="'.$file_name.'"'); header('Content-Transfer-Encoding: binary\n'); To vispār varētu kaut kā atrisināt vai ēzelis to unicodu save dialogā kā tādu nevarēs atpazīt?
-
Īsti nevaru iebraukt javascript kodā, ko Tu izmanto ģenerēšanai, bet iespējams ka viņš kaut ko līdz galam nesaģenerē. Es izmantotu inputu ģenerēšanai nevis innerHTML un tad rakstītu ar tekstu, bet gan veidotu jaunu elementu ar document.createElement('input') un tad pievienotu viņu formai (form_element.appendChild(input_element)), nu kaut kā tā.
-
No jautājuma nav īsti zināms kādi ieraksti un kā ir saistīti, tomēr ja datubāze pieļauj relationshipus, tad iespējams ka tos varētu izmantot.
-
Paskaties kas Tev vispār ir post masīvā: echo('<pre>'); print_r($_POST); echo('</pre>');
-
Ja Tu domā ielikt kā kāda elementa backgroundu, tad nevar, ja Tu gribi lai elementu saturs nepalien zem flesha, tad var mēģināt parametram 'wmode' piešķirt vērtību 'transparent' ieliekot flešiņu lapā, te var palasīt. Php failam kā tādam backgroundu neliek, css vērtība background ir html elementiem, pie tam tur var ielikt tikai bildi (ja neskaita krāsu, bet tā jau nav kaut kāda objekta ielikšana).
-
Njā, būs vien jāmeklē kāds risinājums..
-
U document.onmousemove strādā pareizi. Spriežu ka y ir nepareizs vienkārši tāpēc ka pogai kas ir lapas augšā y koordināti uzrāda 600 ar kaut cik kaut gan nevajadzētu pārsniegt 50. Šis bags ir tieši uz input elementu, ja spied uz div vai arī uz document.onmousemove viss strādās precīzi. Man ir safari uz macintosha, par windowsīgo nezinu, vajadzēs pārbaudīt, bet ja tas piemērs ko es iemetu rāda pareizi, tad uz windowsa arī ir pareizi. Es venkārši taisu lodziņus, kas uzspiežot uz jebkuru elementu tiek izveidots (ja viņš vēl nav izveidots) un tiek parādīts peles koordināšu vietā. Tagad sanāk tā ka uz safari (mac) viņš parādās kaut kur lapas apakšā, bet kad viņu ar peli valkā viss ir normāli, tā kā document.onmousemove strādā pareizi. Man nav ne mazākās nojausmas kāpēc safari nepatīk inputs...
-
Kārtējā dīvainā problēma safari pārlūkā. Doma ļoti vienkārša ir elements viņam uz onclick nosakās peles koordinātes. Viss strādā skaisti līdz brīdim kamēr tas elements nav input ar tipu button. Šajā gadījumā y koordināte nosakās nepareizi. Reku kods: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Mouse coordinates</title> <script type="text/javascript"> function mouseCoordinates(e) { var pos_1=pos_2=0; if (!e) var e=window.event; if (e.pageX || e.pageY) { pos_1=e.pageX; pos_2=e.pageY; } else if (e.clientX || e.clientY) { pos_1=e.clientX+document.body.scrollLeft+document.documentElement.scrollLef t; pos_2=e.clientY+document.body.scrollTop+document.documentElement.scrollTop; } return [pos_1, pos_2]; } </script> </head> <body style="margin: 15px"> <div style="width: 70px; height: 30px; background-color: lime" onclick="java script: alert(mouseCoordinates(event));"></div> <input type="button" id="show_modal" name="show_modal" value="Parādīt logu" onclick="java script: alert(mouseCoordinates(event));"> </body> </html> Uzspiežot uz div elementu viss nosakās kā vajag, kā uz input (ja tips ir submit arī, ar pārējiem tipiem nemēģinaju) tā y koordināte nav pareiza. Nav kādas idejas kur varētu slēpties šī problēma?
-
Nemēģināju vedot, bet doma varētu būt sekojoša. Pirmām kārtām sataisi kādu input lauku skaitītāju, piešķirot tam vērtību 1. Tālāk input elementam onclick izveido funkciju, kas veidos jaunu input elementu, bet pirms izveido elementu (tieši viņa vārdu) palielini skaitītāja vērtību par 1. Tālāk jaunajam izveidotajam elementam onclick pieliec šo pašu funkciju, kas veido jaunu input elementu, bet iepriekšējam elementam onclick piešķir null. Šajā gadījumā uzspiežot uz pirmo input elementu nekas nenotiks, jo onclick ir nonullēt, izņemts ārā, bet uzspiežot uz otro elementu izsauksies tā pati funkcija, kas veidos jau trešo elementu palielinot globālā skaitītāja vērtību par viens. Nu un tā šo ciklu varēs turpināt spaidot uz to inputu cik vien vajag.
-
Php konfigurācijas maiņa ar ini_set un failu augšupielāde.
Maris-S replied to Maris-S's topic in PHP un PHP :)
Bubu, paldies. Ar htaccess labs ieteikums, jo šis iespējams strādās, būs jāmēģina. -
Mēģinājis neesmu, bet liekās ka ja izmanto height, tad parent elementam arī jābūt norādītam augstumam, jo savādāk divam nevar zināt pēc kā vadīties liekot augstumu uz 100%, iespējams ja norāda tabulas šūnai augstumu (pie tam domāju procentos nestrādās), tad height: 100% divam varētu nostrādāt.
-
Php konfigurācijas maiņa ar ini_set un failu augšupielāde.
Maris-S replied to Maris-S's topic in PHP un PHP :)
Bāc, stulbums!! Tikko pats uzmanīgi izlasīju par post_max_size, tur taču ir arī risinājums parādīts, padot caur GET ka tiek sūtīta forma. Tomēr vēl paliek pirmais jautājums vai vispār ir iespēja caur php skriptu nomainīt šīs post_max_size un upload_max_filesize vērtības? -
Php konfigurācijas maiņa ar ini_set un failu augšupielāde.
Maris-S replied to Maris-S's topic in PHP un PHP :)
Es arī izmēģinājos ar failu augšupielādi un man gan viņi bija tukši, tā kā tiem arī būtu jābūt pēc dokumentācijas, viss tieši saistās ar post_max_size, te arī ir aprakstīts kādā gadījumā POST un FILES masīvi būs tukši, šeit arī ir sakars šiem diviem masīviem, tātad ja kopējais sūtīto datu izmērs pārsniedz POST datu pieļauto izmēru tad šie abi masīvi ir tukši. Man nekas nenāk prātā kā varētu noteikt kļūdu par pārāk lielo failu šādā gadījumā. -
Php konfigurācijas maiņa ar ini_set un failu augšupielāde.
Maris-S replied to Maris-S's topic in PHP un PHP :)
Par to jautājuma pacelšanos un runas iešanu tas tā pārnestā nozīmē. :) Nu gluži viss tik vienkārši nav, jo ja faila izmērs pārsniedz pieļaujamo augšupielādējamā izmēru un tajā pašā laikā post datu izmērs nepārsniedz post datiem pieļauto izmēru, tad viss ir kārtībā, bet lieta tāda, ja pateicoties lielam augšupielādējamam failam kopējie post dati pārsniedz post datu pieļaujamo apjomu, tad gan POST, gan FILES masīvi ir tukši. Šajā gadījumā ne tikai nav kur paskatīties kļūdu, bet arī nestrādās viss kas saistīts ar citiem post datiem, piemēram: if (isset($_POST['submit_add'])) { Check for errors... process file upload... } Nenostrādās jo nav jau post masīvā datu kā tādu.