On 19 May 2001, at 12:23,  wrote:
> Kedves  es  !
>
> Potvizsga augusztusban!!! :)))
>
> Robi
Kedves tanar ur!
Mielott vizsgaztat, tanuljon meg olvasni!!! :)))
(Hint: Tudom, hogy hosszu volt, amit a multkor irtam, de nem a veget
kellett volna csak megnezni, az teljesen masra vonatkozott. A kozepen
volt a kerdesre a valasz.)
István
|
On 19 May 2001, at 20:23,  wrote:
> Elso tippem az lenne, hogy probald kidebugolni a hibat. Ha nincsen a
> program De veloper Studio alatt, megeri osszerakni egy workspace-t,
> hogy lasd, mi is torte nik. Ott minden betoltott DLL-t latsz tisztan
> es vilagosabba valik a problema.
Koszi a tippet, de vilagos a problema debug nelkul is, hiba pedig
nincs: minden ugy mukodik, ahogy elvarhato, csak a hianyzo dll nevet
kellene programbol megtudnom... (Egyebkent termeszetesen hasznalok
debuggert.)
> Mas: Gondolom hivtal egy GetLastError() -t a FormatMessage() elott.
> Szerintem e z azert nem segit, mert tul keson van felhivva es az
> utolso rendszer hiba pedig az, hogy nem tudsz irni a pipe-ba.
Igen, ezt probaltam magyarazni.
> Miert nem tudsz irni a pipe-ba?
Mert menetkozben terminalodott a masik process, amitol lezarult a
pipe. De ezt is leirtam a multkor.
> Nekem viszont furcsanak tunik, hogy a rendszer nem irja ki a DLL
> nevet.
Kiirja a message box-ba, de nekem az nem elegendoen jo. Programbol
szeretnem megkapni.
> Sok Sikert!
Koszi, de eleg remenytelennek tunik a dolog.
On 19 May 2001, at 12:23,  wrote:
> Hello!
Szia Tanar ur :))
>
> SetErrorMode(SEM_FAILCRITICALERRORS) eseten elkuldi a rendszer a
> hivo process-nek a hibakodot, amit ott a GetLast Error( )-ral lehet
> lekerdezni. Igy sehogy sem tudod lekerdezni, a dll nevet.
Igen, ettol tartok...
> Nem lehetne ugy, hogy LoadLibrary( )-val toltod be a dll-t? Akkor
> abbol is latod, hogy hianyzik a file, hogy a visszakapott
> HINSTANCE == NULL. Es ekkor tudod a file nevet is.
Sajnos az nem megy. A parent meglehetosen nagy program, sok dll-lel,
nem lehet kezzel load-olosra atirni, meg annyit nem is erne a dolog...
> Remelem hasznalhato. Ha lesz egy kis idom, utananezek rendesen. Ha
> valaki jobbat tud irjon. Bar ez a Windows Psychologic... :)))
Koszi!
On 20 May 2001, at 22:08, bLn  > wrote:
> A debuggerem szerint Win98 alatt az uzenet egy egyszeru MessageBox
> hivas, amit kozvetlenul a KERNEL32.DLL (ring 3) ad ki az
> USER32.DLLnek!!!
Aranyos! :))
> > dll nevet? A CreateProcess egyebkent normalisan visszater miutan
> > elinditja a process-t, es mihelyt a pipe-ba akarok irni valamit,
>
> Ez biztos? Win98 alatt 0 val ter vissza, es a FormatMessage(...,
> GetLastError(), ...); korrekt hibauzenetet ad (a DLL neve nelkul).
Biztos. En is csodalkoztam eloszor, de vegulis ertheto a dolog. Az NT
a programokat nem betolti a memoriaba, hanem memory mapped file-kent
kezeli. A map-peles utan bizonyara megkreal egy processzt, es a dll-
ek betoltesevel (pontosabban map-pelesevel) mar a processz fog
foglalkozni, ugyhogy a CreateProcess-nek csak ennyi a dolga. Bar
ilyen felosztast tudna a win98 is csinalni, de ugy tunik, az mashogy
mukodik.
> Nekem csak az jut eszembe, hogy ha CreateProcess() == 0, akkor
Pontosabban NT eseteben ha a masik processz ERROR_WAIT_NO_CHILDREN-
nel terminalodik...
> megnyitod a process moduljat es megnezed hogy megvan-e minden
> importalt dll. IMAGEHLP hivasokkal eleg konnyu megcsinalni.
> Csunya egy megoldas, nem is mukodik mindig (pl ha futtatasi jogod
> van de olvasasi nincs).
>
> Nagyon kell abba hibauzenetbe a dll neve? :))
Nagyon jogos kerdes :)), ennyi erofeszitest nem er meg a dolog :(
Koszi azert,
István
-- Istvan Marosi -- http://www.sch.bme.hu/~marosi --
-- Recosoft Ltd. -- mailto: --
|
On 20 May 2001, at 21:03,  wrote:
> Pista biztosan elmondja majd jol is :)
Nem tudom, ram gondoltal-e? :)
Annyi hozzatennivalom lenne csak, hogy egy szam kettes komplemenset
ugy kaphatjuk meg legegyszerubben, hogy vesszuk az egyes komplemenset
(vagyis a bitenkenti negaltjat) es hozzaadunk 1-et. Ugyanis ha a
szamot bitenkent negaljuk, akkor ennek (vagyis az 1-es komplemensnek)
es az eredetinek az osszege csupa 1-es lesz, ehhez 1-et hozzaadva mar
0-at kapunk (persze tulcsordulassal), vagyis eppen kielegiti azt a
definiciot, amit Te irtal.
Az adott esetben: 11 dec = 0000 0000 0000 1011 bin (8+2+1)
Ennek 1-es komplemense: 1111 1111 1111 0100 bin
Ennel 1-gyel nagyobb szam: 1111 1111 1111 0101 bin = -11 dec
A tizedestort atirasa normalizalt tizenhatodostortre temahoz annyit
tennek hozza, hogy ha a feladatot 16-os szamrendszerben kell
megoldani, akkor a normalizalasnal sem lehet 2-es alapot hasznalni,
csak 16-osat. Masik dolog: irtad, de en meg jobban kiemelnem, hogy
nagyon sok esetben (a jelen esetben is) vegtelen tizenhatodos tort a
pontos eredmeny; egy gep viszont ennek csak veges kozeliteset tudja
abrazolni! Ebbol adodnak azok a kerekitesi 'problemak', amik olyan
meglepoek tudnak lenni lebegopontos szamok hasznalatakor. (Itt a
listan is volt mar ilyen kerdes...)
István
-- Istvan Marosi -- http://www.sch.bme.hu/~marosi --
-- Recosoft Ltd. -- mailto: --
|
Sziasztok!
Ugy alakult, hogy ki kellene javitanom egy Visual Basic programot, amit
persze nem en irtam.
A program tobbek kozt BMP-t ment ki lemezre. A rajban mindig csak
2 szin van, de a kimentett file 256 szinu.
Hogy lehet azt megoldani, hogy csak ket szinnel mentse ki? Meret miatt
lenne erdekes a dolog. Vagy ha van olyan eljarasa valakinek, ami GIF-be
ment, az is igen jol jonne.
kosz
Zotyo
|
