Sziasztok!

Programbol nyitnam meg a sugo fajlt 16 bites Windows programbol a
     WinHelp (hDlg, szHelpFile, HELP_CONTEXT, ContextID);
hivassal. Nem tudom, hogy miert, de ugy tunik, hogy NT alatt ket sugo
program is letezhet, mert feljon a sugo program, es azt mondja, hogy a
megadott sugo fajl nem ervenyes. Ha a sugo open funkciojaval probalom
megnyitni, szinten hibat jelez. Eddig kerek is lenne minden, de ezek
utan eloveszem az Intezot, es a sugofajlt megnyitva az tokeletesen
mukodik. Megneztem mindket esetben a program nevjegyet, es a ketto nem
ugyanaz, ezert gondolom, hogy ket kulonbozo program indul el a ket
esetben. (Nalam nem NT fut, ezert csak felhasznaloknal jelentkezik a
hiba, es ott sem mindegyik gepen.)

Tud valaki tanacsot adni ez ugyben?

--
Udv.:
Joco

Sziasztok!

Van egy ado vezerlom, egy hozza kotott datagrid, es a mezokhoz egy-egy
textbox.
Mivel ez egy atmeneti adatbazis, kilepeskor ki kellene torolni. Abba
mar-mar belenyugodtam, hogy az ado1.Recordset.Delete adAffectAll -ra
lehal, hogy ebben a kontextben nem engedelyezett (???), de ha ezzel a
for ciklussal maszok vegig rajt, akkor
1. : Ha senki nem bantotta a datagridet, akkor szepen lefut
2. : Ha kattintgatott a user (egyelore en :-) a datagriden, akkor
elszall, mindenfele valtozatos hibaval, de leginkabb azzal, hogy a
legutolso update ota megvaltozott az adatbazis. A kikommentezett ket
update sem kulon, sem egyutt nem oldotta meg a problemat.
(Egyelore ugy cseleztem ki, hogy nem az unload, hanem a form load
esemenye torli ki az akkor meg erintetlen vezerlo mellett, de ez igy
piszokra ganyolas...)

Barmi otlet?


Udv: Csabii

Private Sub TempDatabaseClear()
Dim Counter, NumberOfRecords As Integer
    NumberOfRecords = ado1.Recordset.RecordCount
    If NumberOfRecords > 0 Then
        ado1.Recordset.MoveFirst
        ' EZTPROBALTAM ado1.Recordset.UpdateBatch
        For Counter = 1 To NumberOfRecords
        ' EZTPROBALTAM ado1.Recordset.Update
            ado1.Recordset.Delete adAffectCurrent
            ado1.Recordset.MoveNext
        Next
    End If
End Sub

Sziasztok!

Olvastam itt ket valaszt a gyokfuggvenyes kerdesre. A kovetkezok a
hozzafuzni valoim:

1. a leirt kozelites az egyik legjobb, nem igazan erdemes gyorsabbat
keresni, tekintetbe veve egyszeruseget, es a 2.-ben leirtak miatt.
Egyebkent vannak olyan, adott szamra kihegyezett szamitas eljarasok,
amik meg sokkal gyorsabban dolgoznak (ha mindenkeppen bele akarod asni
magad ilyesmibe, egy jo konyvtarban nezz meg nehany Numerikus analizis
cimu konyvet (nem elsosorban tankonyvet:); ezekben erthetoen van
leirva az algoritmus, mar ha van bennuk).

2. 'recosoft' sajnos figyelmen kivul hagyta, hogy az altala szamolt
'kovetkezo kozelito ertek' sqrt2-e/2 alakja nem azt jelenti, hogy a
hiba felezodik! Nem egy uj bit keletkezik iteracionkent, hanem a
helyes jegyek szama minden lepesben _megduplazodik_, ami azt jelenti,
hogy az emlitett 1E6-jegyu pontossagot, ha elso kozelito ertekkent
1-et valasztjuk, 20 azaz husz lepesben erjuk el (mert 2^20 >= 1E6)!
Ettol persze a sok jegy miatt meg nem lesz nagyon gyors a szamolas.

3. A sokszamjegyu szamolasrol: egyszer valamikor volt nekem egy
pascalos rutinkeszletem, ami pont erre keszult, de mar nincs meg, es
nem tudom, mi volt a neve, sem hogy hol talaltam...
 Ha hajlnado vagy ilyesmit irni, akkor nehany tanacs:
*** elegendo az (elojeles) osszeadas es a szorzas muveletet
'jegyenkenti vegrehajtas'-szeru modon implementalni, mert a kivonas
trivialisan, az osztas pedig, ill. tkp. a reciprok-szamitas, (pl.
sqrt2-nel ez pont eleg) elvegezheto az x2 := x1*(2-a*x1) formula
alapjan (ahol a:a szam, amelynek a reciprokara kivancsiak vagyunk, x1,
x2:kozelitesek). Meglepo, de igy iteralva gyorsabban szamithatunk
reciprokot, mint az osztas klasszikus muveletet vegrehajtva!
Ez a keplet viszont (es sqrt2-nel ez megint szerencses) 1 < a, xn < 2
eseten konvergens; es ugyanugy, mint a gyok-kozelito, ez is minden
lepesben duplazza a helyes jegyek szamat.
*** az osszeadas trivialis modon (de: atvitelek!), a szorzas pedig a
kovetkezokeppen programozhato:
ciklus i=1..szamjegyszam
  temp=0
  ciklus j=1..i
    temp=temp+elsoszam_jegyei[j]*masodikszam_jegyei[szamjegyszam-j+1]
  cikl.
  eredmenytemp=eredmenytemp+temp*'helyiertek=i'
cikl.
ciklus i=2..szamjegyszam
  temp=0
  ciklus j=i..szamjegyszam
    temp=temp+elsoszam_jegyei[j]*masodikszam_jegyei[szamjegyszam-j+i]
  cikl.
  eredmenytemp=eredmenytemp+temp*'helyiertek=szamjegyszam+i-1'
cikl.

Az algo. vegen az eredmenytemp-ben van a vegeredmeny. Az eredmenytemp,
az elsoszam es a masodikszam legyenek 'hosszuszam-tipusuak', a temp
pedig a hosszuszam-tipus szamjegyeit alkoto tipusu lehet.

*** a 'hosszuszam-tipus' tehat egy tomb-tipus, ami celszeruen nem
byte-okbol (!) all, mintha szamjegyenkent dolgoznal, hanem pl.
pascalban comp tipusu (64-bites, copr. altal kezelt egesz tipus), ez
ugyanis 20+ tizedesjegyet kezel. Az elozo algoritmus temp valtozojanak
szerepet megertve, ill figyelembe veve a szamolasi igenyeket, megsem
20, hanem mondjuk 8-10 jegyet kell figyelembe venni a 20-bol, a tobbi
a szorzasok, osszegzesek elvegezhetosege miatt kell.
Tehat az 1E6 szamjegyet ~1E4 darab comp-ban tarolod es kezeled, a
num.proci sebessegevel.

*** az osszeadasnal, szorzasnal annyi jegyet kell csak feldolgozni
(szamjegyszam!) amennyit a kozelito modszerek helyes jegykent mar
'elertek' (az n-ik lepesben 2^n jegy). Igy a munka felet megsporoljuk.

Egyenlore ennyi.
Jo munkat/sok szerencset!
Takacsd

>Felado :  [Hungary]
>((a/b)+b)/2
>Peldaul ha kettonek keresed a gyoket, es ennek a kozelito erteke 1
>(a=2, b=1), akkor a keplet alapjan 1.5-ot kapsz, es ha ezzel is
>elvegzed a muveletet 1.41666667 es igy tovabb (a kovetkezo:
>1.414215).
>Ha ezt tetszolegesen sokszor megcsinalod, akkor mar kozel fogsz jarni
>a gyok 2-hoz.
Ehhez meg annyit, hogy az algoritmus "hibaturo", azaz, ha valahol
elrontod a szamolast, akkor a kovetkezo korokben ugyis "megjavul"
(Intel rulez :-) ). Ennek kovetkezteben a kiindulo ertek is akarmennyi
lehet (42 rulez :-) ).

A'kos

Udv

Adott a kovetkezo kod reszlet (VC++):
        ...
        CFtpFileFind m_FtpFileFind(m_pFtpConnection);
        BOOL b;
        b=m_FtpFileFind.FindFile();
        while (b)
        {
                b=m_FtpFileFind.FindNextFile();
                ...// itt megy bele egy listbox-ba
        }
        ...
Felmegyek egy ftp szerverre, majd lekerem a file-ok listajat, le is
jon. De probalok konyvtarat valtani (m_pFtpConnection-
>SetCurrentDirectory("akarmi")), es onnet nem mukodik a FindFile. De
ha GetCurrentDirectory-val rakerdezek az aktualis konyvtarra, akkor
minden rendben be ment, csak eppen nem lehet listazni... Mondok neki
egy SetCurrentDirectory("/")-t. Listazas nem megy, de
GetCurrentDirectory-val megint a helyes erteket adja ("/"). Mitol
lehet, hogy csak egyszer mukodik (connect utan) a FileFind?

A valaszokat elore is koszonom...
                                                         bye...
> ---------------------------------------------------------------
E-Mail: mailto: (PMail32 v3.12b)

Sziasztok !

Lehet hogy mar ment ez a tema regebben a listan, de csak email
lehetosegem van ezert nem tudok az archivumban keresni.

Szuksegem lenne egy olyan algoritmusra, amelynek bemeno parameterei az
ev es honap, es megadja hogy az adott honap elso napja milyen napra
esik. (hetfo, kedd ...)

Elore is koszonom !

Remek.  API war-ban meg ugy se voltam ;-)

  writes:
>>> van, a ket legnagyobb rivalis a Qt es a GTK, de regebben letezett
>>> egy szinte monopol helyzetben levo, a Motif.
>> Regebben letezett? >Milyen browser-t hasznalsz Linux alatt? ;-)
>> Raadasul, a Qt & GTK progyk nem annyira portabilisek unixokra, mint
>> a Motif.
> Most nem ertem miert kotozkodsz? OK, a Motifot ma is sokan
> hasznaljak -- bocsanat spongyan fogalmaztam --, de inkabb csak olyan
> cegek, akik nem biznak meg az ingyenesen elerheto konyvtarakban
> (tipikus hozzaallas: "De ha megis valami gond van, akkor ki fogja
> tartani a hatat?". Nyilvan, ha veszi valakitol a libeket, akkor a
> kereskedonek tartania kell a hatat, majd egy fel eves kesessel
> kijavitja a hibat -- ha egyaltalan elismeri, hog hiba es, hogy az o
> hibajuk --, az ingyenes open source kodot meg hat-tartas nelkul a
> ceg sajat programozoja kijavitja ha kell, majd mindenki mas szamara
> is elerhetove teszi).

Ez itten tomeny FUD.  (Ezert is "kotozkodok")
1) Motifot alltalaban azert hasznalnak, mert kiforrott, jo regen a
piacon van, valamint igen sok olyan (szabadon elerheto) widget kering,
ami motifra epul. Vagyis sok kod van megirva Motifban. Arrol nem is
szolva, hogy igen sok doksi letezik Motifhoz. (Entry level is)
2) Ha kod kell, akkor nezz el a http://www.lesstif.org -ra, vagy a
http://www.opengroup.org/openmotif/ -ra
3) Szep-szep ez az open source dolog (En is szeretem) de oszinten,
szerinted az application programmerek hany szazalekanak van meg ahhoz
a tudasa, hogy egy API kodjaban kepes legyen megtalalni a bugot? (Ide
vago link: http://www.igpm.rwth-aachen.de/~albrecht/hungry.html) Hat
meg ha csak azt nezzuk, akine van kedve/ideje atnezni azt a jopar 1000
kodsort, hogy tenylegesen megtalalja?

> A Netscape es az a nehany alkalmazas, ami Motifot hasznal mind
> statikusan linkelt, nincs semmilyen Motif konyvtar a gepemen, ami
> persze nem azt jelenti, hogy ettol mar nem lesz Motifos a cucc.
> Wordperfect is Motifos.

Ha ilyen sok motifos cuccot hasznalsz, akkor nem lenne erdemesebb
felpakolni a libeket, & dinamikusan linkelt verziokat hasznalni?

-- 
Imre Palik
            Microsoft Certified Angry OS Rebooter