Visual Basic

B

BIVSI ZEKEN

Početnik
Poruka
36
Imam jedan problem. Svaki program koji napravim u visual basic-u prilikom ukljucivanja ima format koji je bio prilikom njegovog pravljenja. Prilikom maksimiziranja programa svi delovi interfejsa programa ostaju u formatu koji su bili iako je program maksimiziran. Da li je moguce napraviti da se prilikom maksimiziranja programa maksimiziraju i njegove vidljive alatke.
 
Nisam siguran da sam te bas razumeo.
Koliko sam uspeo da raztabirim, ti bi da se i alatke, dakle elementi dijaloga, takodje povecaju saglasno maksimiziranom prozoru. Da dugme postane vece, da get polje postane vece ili neki combobox itd.?
Ako je to, nazalost neces to moci uraditi. Neko mi je jednom pomenuo da navodno postoji neki program koji ume da "razvlaci" elemente dijaloga kako povecavamo prozor, ili "skuplja" kontrole ako smanjujemo dijalog... Koliko ja znam, to ne postoji
Onako, cisto za ispitivanje, pokuao sam da napravim da se moje kontrole smanjuju saglasno izmeni velicina prozora. I ne samo to vec i pozicije kontrola u odnosu jedni na druge. Mnogo komplikovano i neupotrebljivo. Jer, prvo sto ce korisnik uraditi je da smanji dijalog sto vise a onda se kontrole pocinju "gurkati" medjusobno, preplitati i sve zajedno ninasta ne lici.

Pojasni malo sta ti znaci "...ima format koji je bio prilikom njegovog pravljenja " , mozda te nisam razumeo.
 
Ako je to sto mislim, sigurno ne moze, pa ni u .NET :(
Naime, ako zeli da se kontrole povecavaju u dimenzijama ili smanjuju a istovremeno podesava njihov raspored i medjusobni raspored proporcialno tekucoj velicini prozora, a sve to kako povecavas ili smanjujes sam prozor - to jos nisam video ni u jednom programu, ma u cemu je pisan.
Ako misli na nesto drugo onda nisam razumeo.
 
zato sam i spomenuo VStudio 2003 :) tj nisam ali nemaveze...
upravo to - povecanje kontrola ili smanjivanje moze da se zbudzi na taj nacin...e sad koliko to na kraju dobro ispadne i koje su mogucnosti nemam pojma posto to nikad pipnuo nisam....
 
Obzirom da je ovo samo tumačenje pitanje da li sam i ja dobro shvatio.

Ono što se obično radi je da se zadrži aposlutna pozicija pojedinih kontrola zadrži, a da se ostalima menja veličina u zavisnosti od trenutne veličine prozora u kojima se one nalaze. U tom slučaju, se recimo visnia polja za unos ne menja, ali se menja njegova dužina, na primer kako bi korisnik mogao da vidi što više teksta koji je unet u to polje. Obično takvi objekti imaju neku minimalnu veličinu ispod koje smanjivanje njije moguće inače se ništa ne bi videlo. Da li je to ono što je autor tememhteo da uradi ili ne verovatno će on sam znati da odgovori.
 
Ne znam kojim bi programom ili nacinom ovo postogao, ali vec godinama unazad sam odustao od traganja za resenjem ovoga o cemu (valjda) pricamo.
Pre podosta godina, razvila se velika diskusija bas o tome na internetu i nakon meseic diskusije, niko nije mogao da izadje sa resenjem koje bi zadovoljilo kriterijume.

Svi mi koji radimo sa Windows GUI i kontrolama umemo da manipulisemo njihovim dimenzijama, kada je to moguce i dozvoljeno. Problem je sto nije dovoljna manipulacija samo dimenzijama vec i pozicijama kontrola na ekranu, u zavisnosti od trenutne velicine prozora. To bi bila nocna mora zahvatiti programskim resenjima, pogotovo kod ekstremnih vrednosti.

I na kraju, ne mogu se sve dimenzije svih kontrola menjati. Get polja mozete menjati po duzini ali cesto ne i po visini na primer.

Dakle moj odgovor, sudeci prema dugogodisnjem iskustvu - ne moze, ili barem nije upotrebljivo.
Nekad davno se secam da je neko najavio neki softver koji naknadno moze dijaloge i prozore da menja po potrebi ali ga evo do danas ne videh.

A nisam do sada jos video softver koji menja dimenzije kontrola i njihove medjusobne razmere pozicioniranja, kako korisnik po zelji menja velicinu prozora.
 
Ako sve što može da se uradi se iskoristi za sve kontrole koje se nalaze u okviru jedne forme, dobiće se sigurno nešto neupotrebljivo.

Međutim način pozicioniranja kontrola je ono što daje veću ili manju slobodu pri dizajniranju. Ako za svaku ivicu kontrole može da se definiše da li je njena pozicija apsolutna, relativna ili procentualna u odnosu na ivicu samoga sebe, nekog drugog elementa ili samu formu na kojoj se kontrola nalazi, onda to pruža sasvim doovljno mogućnosti da se elementi sami rasporede na zadovoljavajući način pri promeni dimenzija forme.

Niko ne očekuje da se dugme koje je bilo u gornjem desnom uglu, pri promeni dimenzija nađe u donjem levom, jer je to totalna promena izgleda i nema veze sa ovim o čemu diskutujemo.
 
juznivetar:
Moze se sve ovo sto je doticni trazio rijesiti. E sada sa Vb nemam iskustva, pa neznam, al' win32 api ce to rijesiti bez vecih problema.
Kliknite za proširenje...
Sucure, voleo bih da si u pravu...
To bi mi zaista jako trebalo, ali vec godinama unazad nemam nikakve iluzije da li se to moze izvesti. Za sada, kako stvari stoje, nijedan kompajler koji sam koristio to nije mogao ni blizu da uradi.
Moze se rudimentarno preracunavati pozicije kontrola, menjati njihove dimenzije itd.. Ali da to bude precizno automatizovano kad korisnik izmeni velicinu i dimenzije prozora, ne moze biti upotrebljivo.
Zamisli samo da korisnik menja dimenzije prozora vise po visini nego po sirini, dakle kompletno menja osnovne relativne rasporede kontrola. Nema tog softvera koji ce moci da korektno odradi in-time:
- izmene dimenzije svake kontrole
- podesavanje novih odnosa i razmaka izmedju svih kontrola
... pogotovo sto neke kontrole i ne mogu da se izmene tako lako po nekoj od dimenzija (vertikali ili horizontali)...

Ako si nasao nacin da se to ostvari, bilo bi sjajno, ali sumnjam. Mozemo mi da teoretisemo koliko hocemo ali ponavljam, jos nisam video nijedan program koji se ponasa onako kako ovde diskutujemo.
Sta si mislio kad si pomenuo da se ovo moze resiti sa Win32 "bez problema"? Ako stvarno mozes, bio bih ti zahvalan kad bi mi nesto pokazao, jer sva moja iskustva govore da ne moze.
 
Nije to stvar kompajlera, već okruženja u kome se radi i da li postoji ili ne postoji nešto što se zove Layout Manager. Ne znam šta znači in-time u ovom slučaju, tj. koliko zakšnjenje u odnosu na promeu geometrije prozora se još uvek smatra in-time, ali ukoliko nema prevelik broj komponenti nije problem sve prikazati in-time.
Ne razumem zašto je ne proporcionalna promena veličine prozora toliki problem. Možda ima neki primer kojeg nisam mogao da se setim, ali takava promena nije ništa drugačija od proporcionalne, jer u svakom slučaju sve pozicije elementa moraju ponovo da se izračunaju.
 
Ako probas to i da ostvaris - videces :) Naprosto nije upotrebljivo.
Kad sam rekao "in-time" mislio sam "za vreme same promene" u smislu, kako korisnik promeni dimenzije prozora, da se odmah vrse preracuni i menja displej.

Bas zbog tvoje poslednje recenice, takve su izmene nemoguce a da bi bile upotrebljive.
Moze to uraditi programer koji ozbiljno poznaje sve objekte klasa kontrola, pa moze koristiti podatke dimenzija. Ali, kao sto i sam znas, mnogo ljudi koristi forme na koje slazu elemente i tu se otprilike njihovo znanje o kontrolama zavrsava. Nemaju dovoljno znanja da sada jos i napisu svoju funkciju za kontrolu dimenzija prozora i da reaguju tako sto ce napisati kod koji ce proporcionalno smanjiti ii povecati kontrole i jos ujedno i ispomerati ih tako da imaju slicna rastojanja j relativne pozicije.

Onaj ko tvrdi da to ne bi trebalo biti problem, neka pokusa da napise takav program i baci ga ovde. Ustanovice da ce imati sedu kosu vrlo brzo i jos brze odustati od ideje. Nazalost.
Ili, neka da link za ijedan program koji to radi kako valja, bilo gde a netu.

Primetili ste da ako imamo mali dijalog sa recimo dva geta i dva dugmeta, velicine na primer 200x100 i kad ga povecamo na 1000x700 na primer, get kontrole i dugmici ostaju iste velicine i istog medjusobnog rasporeda, samo je sve pomereno prema gornjem levom cosku. Ono sto bi mi svi zeleli ovde je da getovi (kontrole) butu mnogo veci, font koji prima get (ili neka kontrola, dugme na primer) da bude umesto 10 velicine 20 ida dugmici budu veci a sve to da se kontrole lepo razmeste po ekranu jer je sada mnogo veci.

Ima tu mnogo elemenata u igri, osim pukog povecavanja dimenzija kontrola. Ako je kontrola veca po dimenzijama, moraju i fontovi biti veci itd. A sve to da se desava dok korisnik misem veselo i brzo menja dimenzije prozora napred,nazad i raduje se izmenjenim slikama na ekranu... sve dok windows ne "prsne" od napora, ili izracunavanje i pozicioniranje kasni za izracunima ili memorije nikad dosta ili procesor ne stigne sve da odradi itd,itd,...

Windows API kakav je sada, jednostavno nije fleksibilan za tako sta. Ponavljam, jos nisam video od kad je Windows 3.0 izasao, takav program.
 
"Za vreme same promene" može da bude poprilično zahtevno, tako da bi to možda radilo samo do određenog broja elemenata. Kada ih ima više od toga ništa od "in-time".

Mislio sam je ovde reč o tome da elementi što bolje iskoriste prostor koji je dat, a ne da se pravi zanimacija za korisnika. Mea culpa. Sem toga pri promeni veličine prostora koju prozor zauzima, veličina fonta ne bi trebala da se menja, već samo dimenzije pojedinih komponenti, jer je ideja prikazati što više informacija, a ne zumirati prikaz. Za promenu veličine fonta zaduženo je podešavanje u okviru Windowsa ili neka posebna opcija u okviru samog programa.

Ako uzmemo primer sa dve get (text box) kontrole i dva dugmeta, ono što ima smisla je da se get kontrole menjaju svoju širinu i možda vertikalnu poziciju, ako baš neko voli da zadrži postojeće odnose pozicija, a dugmad eventualno i visinu, mada bi onda delovala pomalo nezgrapno u odnosu na text box kontrole.

Primer kod koga se sve menja predstavlja praktično zumiranje prozora odnosno svih elemenata u okviru njega i to verovatno da može da se ostvari i bez potrebe za "in-time" varijantom, jer je verovatno posle otvaranja prozora jedina akcija korisnika na temu promene dimenzija istog - maksimiziranje.
 
Pod onim bez problema, mislio sam na samu promjenu pozicije i dimenzija. E sada druga je prica same kalkulacije tih promjenjivih i njihova preciznost i krajnji izgled aplikacije, to je vec stvar ukusa.
codemaker:
Moze to uraditi programer koji ozbiljno poznaje sve objekte klasa kontrola, pa moze koristiti podatke dimenzija. Ali, kao sto i sam znas, mnogo ljudi koristi forme na koje slazu elemente i tu se otprilike njihovo znanje o kontrolama zavrsava.
Kliknite za proširenje...
Stalno pricam o razlikama i o prednosti win32 api nad recimo VB-om. I evo dodjosmo do klasicnog primjera. Upravo zbog ovakvih stvari se nemogu porediti VB "programeri" i win32 api.

A sto se tice kontrola koje se nemogu resizeovati po nekoj osi, da kazem da postoje, al' one ne predstavljaju nikakav problem. Jer je fazon sto programer u win32 manipulise svim bitnim podatcima o kontroli. I nikakav problem nije predati kao y-pos parametar kontrole neku varijablu y_mojakontrola. A kada imas svoju varijablu na toj poziciji, ostalo je samo kalkulacija i determinacija programera kako on zeli da se ponasaju kontrole prilikom promjene velicine prozora.
 
Sve to jeste tako kao sto kazes, ali za sada u teoriji.
Kad budem prvi puta video program koji efikasno radi redimenzioniranje kontrola i njihovo proporcionalno repozicioniranje, verovacu da je praksa zazivela. Ovako, tvrddnja da moze, ostaje samo tvrdnja.
Do sada u zivotu nisam video tako nesto, verovatno postoji razlog za to. Da li su to ogranicenja Win API-ja ili napisanih klasa ili njihovih interpretacija unutar kompajlera, ne znam ali jednostavno - nema takvog programa.
Mozemo mi da teoretisemo, ali praksa nas demantuje.

Doduse, nije mi bas najjasnije, ko su to Win32 programeri, ali verovatno mislis na one koji koriste Windows API direktno bez predprocesiranja ili neke, uslovno govoreci "enkapsulacije" (mada nisam dobar izraz upotrebio)

Meni bi stvarno jako pomoglo da mogu da korisnicima ponudim varijantu "fleksibilnih" dijaloga/prozora, jer su me za to mnogo puta pitali, ali eto, nema.

@Bojan
"Sem toga pri promeni veličine prostora koju prozor zauzima, veličina fonta ne bi trebala da se menja, već samo dimenzije pojedinih komponenti, jer je ideja prikazati što više informacija, a ne zumirati prikaz"
Bilo bi besmisleno da se ne menja i velicina fonta saglasno. Zamisli samo velicinu fonta za dijalog 200x100 i na njemu jedan get na primer, a onda se poveca na 1000x700 i get bude velicine autobusa a font unosa bude i dalje sitnih 10, viseci tako "u prostoru"...

Previse problema a premalo realizacije.
Vise godina nekada sam se zanosio da to mogu realizovati. Sto rece Sucur, tehnicki je moguce cackati po kontrolama, jer ako ih Windows ume nacrtati, a klasama imam pristup, mogu i ja da im menjam dimenzije.
Mnogo bi mi znacilo da je to moguce implementirati besprekorno, ali nazalost - mrka kapa.
Ako neko ima informaciju o nekom programu koji to moze, voleo bih da mi kaze, barem da imam neku nadu :)

A mozda ce GUI sistem Viste i sama Vista sa API-jima imati neke novosti, ko zna
 
Ne slažem se da bi bilo besmisleno bez promene veličine fonta. Kao primer dovoljno je da postoji neka lista, koja kada se poveća dimenzija prozora prikazuje više podatka o svakom elemntu liste kao i veći broj elemenata. Ukoliko se zajedno s tim poveća i font, onda je menjanje veličine prozora zaista besmisleno.

S druge strane, za prozor gde postoje samo dva tekst polja i dva dugmeta, možda bi moglo i da se nađe opravdanje da se za povećanjem dimenzija prozora poveća i veličina fonta, ali sam i dalje protiv toga.

Da ne bi sve bila samo teorija, probaću da napravim neki primer.
 
Bilo bi odlicno ako smo se razumeli, da napravis neki demo.
Imaj na umu da nije dovoljno samo povecati, pa smanjiti i to je to.
Izmena dimenzija prozora mora biti proizvoljna, (na smanjenje do neke razumne granice) i da se to sve desava u real-time.
Neophodno je i zadrzavanje proprocionalnih rastojanja izmedju kontrola.

Izmena velicine fonta je neophodna za get, dugmad, checkbox (labels), radiobox (labels) a potrebna je i za labele liste i elemenata liste. Tacno je da se izmenom velicine liste na primer moze staviti vise (ili manje) elemenata (kolona, redova) ali je i to diskutabilno ako i inace ima da se prikaze samo dve kolone necega. A rastegnemo listbox sa sirine 300 na sirinu 900 ... fonr ostaje isti i mnogo praznog prostora sa desne strane? Zato mislim da bi trebalo i font u listbox podacima menjati

Ajde kad budes imao vremena...
 
Verujem da smo se razumeli. Da li će biti real-time ili ne, zaivsi od brzine računara, ali i to može da se dotera ako se pusti na nekom računaru koji nije dovoljno brz da sve to odradi tako što će se ažuriranje elemenata u prozoru uraditi tek ako korisnik ne promeni veličinu prozora tokom nekog zadatog vremena, na primer 200ms.

Obično podataka o nekom elementu u listi ima više nego što može da stane, tako da ima razloga zašto nije zgodno menjati veličinu fonta kojom se prikazuju elementi u okviru liste. U slučaju dve kolone koje se vide i pri minmalnoj dozvoljenoj veličini prozora zaista nema neke koristi od povećanja širine prozora.

Biće ovih dana.
 
Da, to kako jeste funkcionise ali je veoma rudimentaran primer, nazalost.
Ja sam cak otisao i dalje i napravio mnogo kompleksniji primer, koji mi je dao neku sliku kako to moze izgledati, ali se pojavila gomila problema veoma brzo.
Pogotovo kad sam postavio kontrole ne "nanizane" u red ili kolone i ne "pod konac"

Evo primera dijaloga jedne aplikacije koju sam pre 10 godina radio pa mi kazi da li mislis da se ovakav (pa i komplikovaniji) dijalog moze uraditi bez "gubitaka" da se napravi resize po zelji? (naravno sa limitom minimalne visie i sirine)
Imas li ideju koliko preracuna bi tu trebalo uraditi i kolika bi mogla biti distorzija slike? A sve to u real-time sto se korisnika tice. Kad bi vec imao mogucnost,l siguran sam da bi se igao vise nego sto bi radio. Uostalom, na ovom dijalogu na primer ne bi ni bilo mesta za smanjenje jer bi onda sve kontrole morale biti manje po dimenzijama visine i sirine, samim tim i fontovi a to vec Windows API ne bi tek takopodneo.

finans-1.jpg


Da ne pominjemo da bi onda i sve "staticke" kontrole, dakle one koje imaju ID -1 i ne koristimo ih za programski pristup navodjenjem ID, vec se jednostavno iscrtavaju na dijalogu (razne napisi, labele necega itd.) to bi onda sve moralo da se uzme u obzir prilkom proracuna i samog razvlacenja....

Mislim i da neke kontrole poput geta na primer, ni ne mogu da se smanjuju po zelji (ne govorim o smanjenju po horizontali, vec po vertikali. Mozda u zavisnosti od fonta ali mislim da je to "windows default" system na koji mi nemamo uticaja. Isto vazi i za combobox i mozda jos poneku kontrolu. Dugmici i okviri su specificni i njima je lako manipulisati. Probaj to isto sa get ili combobox.

Moze se zbudziti nesto ali bi bilo daleko od upotrebljivosti veruj mi.
Jer da ima mogucnosti upotrebljivosti, vec bi se nek ozbiljan program nasao koji bi to nudio. Ja takav ne videh.
A voleo bih da moze biti upotrebljivih resenja.

Doduse, sad mi predjosmo u akademske diskusije, ali fakat je da smo u vodama "laboratorijskih diskusija" jer niko od velikih igraca nije takav program uradio. verovatno sa razlogom.
 
Nemam vremena sad da pravim nesto kompleksno, al' code znas i sam da je u programiranju "sve moguce", e sada je na samom programeru sta on smatra zadovoljavajucim rezultatom, al' da se i najkompleksnije aplikacije mogu srediti, mogu. Dakle opet ponavljam, u zavisnosti od ocekivanja i zahtjevnosti finalnog rezultata, morat ce se sam programer manje ili vise potruditi i uloziti manje il' vise vremena, al' ce se stvar rijesiti, tj. moze se rijesiti.

poz
 
Sto se tice zadovoljavajucim rezultatom, meni bi recimo gornji dijalog bio ono sto bi mi trebalo kao rezultat. Jer kad bih njega mogao da resim onako kao zelim, jednostavnije dijaloge bih lakse resavao.

Ma naravno Sucure, u principu sve je moguce. Doduse ja sam mom sinu tako nesto dok je bio jako mali, pricao, a on me pitao kako onda ne moze da vrati sadrzaj paste za zube (uplasio se bednik da cu se naljutiti posto je celu tubu ispraznio radi nekog testa :) )
 
Takodje me zanima kako da se prilikom maksimiziranja promeni polozaj alatki. Tacnije da se ako su one na sredini prilikom maksimiziranja budu na sredini jer kod svake aplikacije one mi ostaju gde su bile pre maksimiziranja primer u gornjem levom uglu. Znaci nije vazno da li menjaju velicinu bitno je da pudu donro pozicijonirane.
 
Prijavite se ili registrujte da biste poslali poruku.

Back
Top