1. |
=?windows-1250?Q?ablak_=E1tszinez=E9se?= (mind) |
6 sor |
(cikkei) |
2. |
Re: szamtek alapjai elso 30 cm :-) (mind) |
40 sor |
(cikkei) |
3. |
Visual C kiiras (mind) |
27 sor |
(cikkei) |
4. |
Visual C ablak kiiras (mind) |
5 sor |
(cikkei) |
5. |
Zip pass toro (mind) |
3 sor |
(cikkei) |
6. |
Re: szamtek alapjai elso 30 cm (mind) |
77 sor |
(cikkei) |
7. |
C++ kontra VB6 DLL (mind) |
17 sor |
(cikkei) |
8. |
OpenGL (mind) |
13 sor |
(cikkei) |
|
+ - | =?windows-1250?Q?ablak_=E1tszinez=E9se?= (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok
A következő kérdésem lenne: Visual Basic-ből hogyan lehet
egy form fejlécét átszinezni ??
Előre is köszi: Edit
|
+ - | Re: szamtek alapjai elso 30 cm :-) (mind) |
VÁLASZ |
Feladó: (cikkei)
|
[...]
>>>- assemblert kartyarol betoltik a RAMba
>>Ez mar felhasznalofuggo - altalaban nem az inditasi folyamat resze.
>Ha't lehet tovabbra is kezzel forditani gepi kodra, de minek?
>Vagy mire mondod, hogy az assembler betoltese felhasznalofuggo?
Ha jol ertem, arrol van szo, hogy az assembly nyelvu programot egyszer
leforditjak gepi kodra, kiirjak mondjuk magnesszalagra, es legkozelebb
csak ezt toltik be, az assemblert nem.
[...]
>De vajon annak idejen, amikor me'g haz vagy szoba meretuek voltak
>a szgepek, es me'g nemigen volt oprendszer, csak loader, meg assembler
>meg a felhasznaloi progi, akkor ki intezte a lyukkartya fej mozgatasat?
>A progi vagy irtak erre kulon rutint, ami szinten ott varakozott a RAMban,
>hogy a programmutato vegre o"ra' is mutasson neha... ?
>Valszeg elobb a progi intezte, aztan irtak rutint.
A programiras gyakran ugy nez ki, hogy az ember megir egy kodot. Aztan
kicsit kesobb szuksege van ugyanerre a funckionalitasra, akkor megirja
megegyszer (gyakran copy&paste-tel). Aztan amikor harmadszor is szuksege
lesz erre, akkor csinal kulon alprogramot, ami vegrehajtja ezt a
funckionalitast, es csak ezt hivogatja. Aztan amikor a kovetkezo
programjat irja az ember, es megint szuksege lesz erra a
funkcionalitasra, akkor fogja az elozo programban megirt alprogramot, es
copy&paste-tel atemeli. Aztan ha egy ujabb programban megint szuksege
lesz ra, akkor ugy dont, hogy csunya lesz a copy&paste, es kulon modulba
(library-be) teszi az alprogramot, es a programok hasznalhatjak ezt az
alprogramot. Ezt a fajta programozast mar a FORTRAN is tamogatta az
1950-es evekben (elegge hoskor? :-)
>Csak azt szeretnem latni, hogy ebbol pontosan hogyan fog felepulni
>a BIOS es az elso oprendszer.
Vegul is a BIOS, illetve az oprendszer elso kozelitesben nem mas, mint
egy rutingyujtemeny, amit a programok felhasznalhatnak. Multitaszk
oprendszereknek persze van egy csomo mas fuknciojuk is (utemezes,
memoriavedelem, eroforraselosztas).
Bye,NAR
|
+ - | Visual C kiiras (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Szia!
Szvsz nem tudod mit csinalsz:-) A problema az, hogy te a nativ GDI-t
akarod hasznalni. VisualC alatt azert ez nem szokas. Persze ez nem az
jelenti, hogy nem lehetseges, de altalaban folosleges macera.
A legegyszerubb megoldas, ha a dialogusablakodhoz, amit a
dialoguseditorral keszitesz, es a classwizard-al matyizod, hozzaadsz egy
textbox-ot. Ebbe aztan nyomhatod a string-eket kedvedre;)
Ha reszletesen erdekel mondhatok konyvet, meg segitek levelben is.
Mnden jot: ZsoltK
>Hello ,
>visual c-ben szeretnek kiirni egy ablakra valamilyen szoveget, tobb
>sorban ugy hogy scrollozni is lehessen. Amit idaig elertem az az, hogy
>kiirom de nem menti el a szoveget (tehat alt-tabozas utan a szoveg nem marad
>meg). Ezt hogyan lehet megoldani ? Az OnPaint metodust viszont nem hasznalhato
m
>mert a szoveg az valtozik (tehat peldaul uzenetek stb). Esetleg mentsek el
>mindent amit kiirtam ?
>Lehet, hogy mindez tul lamer de en meg kezdo vagyok ugyhogy megkoszonnem ha
>valaki felvilagositana (eddig a programming with mfc konyvet olvastam de ott
>mind grafikus peldakat ad)
>
>
|
+ - | Visual C ablak kiiras (mind) |
VÁLASZ |
Feladó: (cikkei)
|
VB-ben van egy olyan boolean, hogy AutoRedraw, és ott annak true-ra állítása me
goldaná a problémát, nem tűnne el a kiírt szöveg. Nem
tudom VC-ben van-e ilyen, nézd meg.
D'nes
|
+ - | Zip pass toro (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Szerintem az Advanced Zip Pass. Recovery igenis brute-force, különben minek kén
e beállítani a karakterkészletet meg hogy milyen
hosszú a jelszó, és minek próbál végig több tízezer kombinációt?
|
+ - | Re: szamtek alapjai elso 30 cm (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> Mire a 8085 elkeszult, mar regen letezett assembler.
> A loadernel me'g hoskori szgepre gondoltam, amikor me'g csak
> kapcsolokkal meg lampakkal (meg lyukkartyaval) kommunikaltunk a geppel.
Az elso gepen, amelyik lyukkartyas volt, meg nem volt beepitett loader -
viszont mar volt konzol, a kapcsolok helyett, amelyrol gepi kodu
adatokat lehetett bevinni. Szepen begepeltek a loadert byte-onkent, hexa
kodban, aztan lefuttattak. Ha elszallt a program (ami a lyukkartyarol
jott) annyira, hogy felulirta a loadert is, akkor reset&goto1 - ha csak
vegtelen ciklusba kerult, arra a jobb gepeken volt megszakitogomb.
> Vegulis igaz, egy loader proginak tenyleg nem kell RAM, eleg neki ROM is.
> Jo, akkor a ROM kezdodik a teljes megcimezheto tartomany tetejen valahol?
A 8085 nullarol indit, igy a ROM is ott kezdodik. A C64-ben a ROM es a
RAM kozos cimeket hasznal: irasnal a RAM aktiv, olvasasnal egy SW
kapcsolo donti el, hogy melyik - indulaskor persze a ROM.
> Es onnan futott es masolta be magat a loader az alatta levo RAMba?
Kisgepeken ezt nem szokas masolgatni gepen belul.
> Vagy mire mondod, hogy az assembler betoltese felhasznalofuggo?
Az assembler a legtobb kisgepen nincs beepitve. MIUTAN lezajlott az
indulasi folyamat, betoltheted es hasznalhatod - de nem szorosan
tartozik a gephez.
> >Indulaskor csak gepi programok futnak.
> Marmint mit nevezel gepi proginak? Mas nem is kepes futni.. :-)
Ugy ertem, a teljes indulas alatt. Sehol sincs olyan, hogy indulas
kozben assemblert toltene be a gep - esetleg benne van a ROM-ban.
> Vilagos, ma mar ezer helyen atirjak a cimeket, na de a hoskorban...! :-))
> Amikor me'g csak egy loader volt felul (ROMban), akkor me'g alatta volt
> az assembler?, alatta a txt?, es az ala, nullara forditodott az igazi
> progi?
Nem. Nullarol indult a ROM (loader), a felhasznalo valahova betoltotte
az assemblert, abban altalaban volt egyszeru szerkeszto is, ami helyet
foglalt valahol (pl. kozvetlenul az assembler utan) a forrasszovegnek
is. Kulon meg kellett mondanod neki a leforditott program kezdocimet -
mar csak azert is, mert a programod abszolut cimeket is tartalmazhatott
(ilyenkor kulonbozo trukkoket lehetett alkalmazni, hogy megis relativ
legyen). Mindezt ki kellett sakkozni, hogy elferjen a memoriaban.
> Hoskori flopirol beszelunk, ugye? Annak a pozicionalasat
> kellett anno a felhasznaloi progi(ba epitett rutin)nak vegeznie tehat?
> Ha igy allunk, akkor mar ertem, hogy mire lesz jo egy kulon flopi rutin.
> De a mai flopik tele vannak IC-kkel, biztosan oka van...
A 3.5" floppy szerintem annyival tud tobbet, hogy jelzi a lemezvaltast.
A sok IC a leptetomotor vezerlese, forgasstabilizalas, stb. lehet. Ezt
nem tudom, de abbol gondolom, hogy a floppy felulete szabvanyos mar jo
par eve - akarmit is tesznek bele.
> A mai flopiknak nincs olyan feluletuk, hogy
> tap, fold, parhuzamos x bit vezetekek, es szokasos handshake jelek?
Ezek vannak es egyszerre egy byte adat megy at (termeszetesen DMA-t tud
hasznalni). Ha intelligens lenne, egy kis memoriaval, akkor nem lenne
ennyire maceras a vezerlese es nem foglalna kozben vegig a gepidot.
> En is ugy erzem, hogy ma ma'r biztos, hogy flopinak szabvanyos felulete
> van, es a PC egyik reszet sem erdekli, hogy a flopi hogyan oldja meg.
Ehhez kepest a "setup"-ban be kell allitani a pontos tipust - pont
azert, mert a gep kezeli.
> De vajon annak idejen, amikor me'g haz vagy szoba meretuek voltak
> a szgepek, es me'g nemigen volt oprendszer, csak loader, meg assembler
> meg a felhasznaloi progi, akkor ki intezte a lyukkartya fej mozgatasat?
> A progi vagy irtak erre kulon rutint, ami szinten ott varakozott a RAMban,
> hogy a programmutato vegre o"ra' is mutasson neha... ?
> Valszeg elobb a progi intezte, aztan irtak rutint.
Igy igaz - amikor mar nagyon untak, hogy folyton be kell gepelni,
betettek (EP)ROM-ba es onnan inditottak (meg a 286-osban is kivalo
foglalatok voltak ROM-oknak, csak azota sporoljak le az alaplaprol, de
kartyan most is beteheto). Ez csak az adott olvasoval boldogult, a
masikhoz mas programot kellett irni - de az akkori programok par tiz,
esetleg szaz utasitasbol alltak, nem kellett kB-okat gepelgetni.
> Csak azt szeretnem latni, hogy ebbol pontosan hogyan fog felepulni
> a BIOS es az elso oprendszer.
Nehany meterrel odebb lesz...
|
+ - | C++ kontra VB6 DLL (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Udv!
Eloljaroban annyit, hogy nem ertek a C++-hoz!
Adott ket C-ben megirt DLL, amelyet VB6-ban szeretnek felhasznalni.
Ha jol tudom, a DLL-ben kellene lennie egy EXPORT bekezdesnek, ahol fel
vannak sorolva azok a fuggvenyek, amelyeket a VB-ben szeretnek hasznalni.
Sajnos ez a bejegyzes hianyzik, es hiaba free a DLL, nincs meg a forrasa.
Arra gondoltam, hogy kellene irni egy harmadik DLL-t, amely a ket DLL
fuggvenyeit kiajanlja a VB szamara.
Ha valaki tudja a fenti megoldast, kerem irjon!
A DLL-ek a http://binary-tenchnologies.com cimen talalhatok.
Elore is THX!
|
+ - | OpenGL (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Kedves Listatagok!
OpenGL programozassal kapcsolatban keresek
neten fellelheto dokumentaciokat, Elsosorban
Delphi-s kornyezetben. Rengeteg pdf-et sikerult
mar osszeszednem, de sajnos mind C-s kornyezetet
targyal.
Akinek van ilyen dokumentacioja, barmilyen formatumban
es esetleg szivesen megosztana azt orommel vennem.
Linkek, ftp cimek, barmi johet.
Elore is koszonom!
fpeter76
|
|