@codefinder -> dringend!

[me-S-on]

ähem , öh eh, .....

Alles klar!
Also, mit anderen Worten bool (__cdecl) ist nur eine Eigenart des Stack-push- und -poppens ( zum Glück bin ich gerade intensiv parallel am Assembler dran!!! ) für die Parameter ,die in der pFileProc übergeben werden .
Oder?

So wie wenn ich eine Funktion an execve() übergebe..
Dann packe ich die Parameter nacheinander in bx,cx,dx, AUSSER die beiden Elemente das Arrays im 2. Parameter von execve; die holt sich die Funktion schön ausm Stack...... ist das vergleichbar?

Also, dieser pFileProc.... ein Zeiger auf den Anfang einer Funktion ....., ich mein, ich weiss, dass man auch in der wndclass das lpfnWndProc-Member so mit einer Funktion initialisiert.... also den Namen derer ohne Klammern entspricht einem Zeiger auf diese, das Program holt sie sich dann schon.
-Ne?

Und dann noch Userdata und pUser data....
->
Zusammengefasst:
pFileProc, pUserData und UserData sind einfach Funktionen, die du in deinem Programm benutzt, daher haste die mit gepostet.
Einfach dein Code, zwingend erforderlich sind die ja nicht bei jedem, ne?

Ok, wenn ich nun die Elemente
-TVINSERTSTRUCT
-HTREEVIEW
- char * ppath;
- char * actpath
- char *newpath
- char *dev_root
nicht alle global machen will, mache ich eine
Funktion global bekannt, welche notwendige Schritte und Variablen übernimmt, um ins TreeVew zu inserten und Images zuzufügen, mache die Suche aber in dieser SerachFolderForFile Funktion.
Dabei übergebe ich dieser einen Pointer auf die vorige Funktion, und SPARE MIR DAMIT TATSÄCHLICH GLOBALE VARIABLEN?????

Ich habe, ( ich bin ja am testen, einen HAUFEN GLOBALER) .

Wenn ich das so richtig entnommen habe. ----
-----
-Die char-cut and replace-Angelegenheit habe ich gestern ebenfalls scheinbar hinbekommen...... allerdings mit mehr oder weniger ANSI-C. Ich habe keine objektorientierten Methoden aus der <string> benutzt.
Könnte ich allerdings mal tun.
Nun schmiert das zwar nach dem dritten Unterordner ab( mit errorcode 6_ Invalid handle) aber das krich ich auch noch hin.
Hope so!
-------------------------------------------------------------------------------

Diese Posts vom (D)Evil !
Echt, nomen ost omen.
Aber ihr beide könnt Euch sicher miteinander messen
-------
codefinder, kanste meine Zusamenfassung noch kurz bejahen, oder verneinen, in den Fragen, die noch kamen?, also die, wo das " " hinter steht?
Dann wärs das fast.....
danke sehr bisher!

[CodeFinder|logged out]

@me-S-on: Warum schreibst du so chaotisch?

[CodeFinder]

(D)Evil schrieb:

Jetzt aber mal im ernst ... dein cString usw. ist bescheuert ^^ Mehr als das ...

#include <tchar.h>
#include <string>

typedef std::basic_string<TCHAR, std::char_traits<TCHAR>, std::allocator<TCHAR> > tstring;

Naja^^, kommt aufs Gleiche raus, wobei man natürlich durchgehend cString/tstring verwenden sollte, jupp:

(D)Evil schrieb:

aja und dann auch

typedef bool(__cdecl* PFILEHANDLER)(const tstring&, void*);

usw ...

konsekutiv ...

Auch wenn ichs nicht geschrieben habe, stimme ich dem trotzdem zu :

CodeFinder|logged out schrieb:

@me-S-on: Warum schreibst du so chaotisch?

me-S-on schrieb:

Also, mit anderen Worten bool (__cdecl) ist nur eine Eigenart des Stack-push- und -poppens ( zum Glück bin ich gerade intensiv parallel am Assembler dran!!! ) für die Parameter ,die in der pFileProc übergeben werden .
Oder?

Joar.

me-S-on schrieb:

Also, dieser pFileProc.... ein Zeiger auf den Anfang einer Funktion ....., ich mein, ich weiss, dass man auch in der wndclass das lpfnWndProc-Member so mit einer Funktion initialisiert.... also den Namen derer ohne Klammern entspricht einem Zeiger auf diese, das Program holt sie sich dann schon.
-Ne?

Genau, das ist damit vergleichbar.

me-S-on schrieb:

Und dann noch Userdata und pUser data....
->
Zusammengefasst:
pFileProc, pUserData und UserData sind einfach Funktionen, die du in deinem Programm benutzt, daher haste die mit gepostet.
Einfach dein Code, zwingend erforderlich sind die ja nicht bei jedem, ne?

Nein, nur pFileProc ist ein Funktionszeiger. pUserData ist ein Parameter der Funktion 'ScanFoldersForFiles'.

me-S-on schrieb:

Ok, wenn ich nun die Elemente
-TVINSERTSTRUCT
-HTREEVIEW
- char * ppath;
- char * actpath
- char *newpath
- char *dev_root
nicht alle global machen will, mache ich eine
Funktion global bekannt, welche notwendige Schritte und Variablen übernimmt, um ins TreeVew zu inserten und Images zuzufügen, mache die Suche aber in dieser SerachFolderForFile Funktion.
Dabei übergebe ich dieser einen Pointer auf die vorige Funktion, und SPARE MIR DAMIT TATSÄCHLICH GLOBALE VARIABLEN?????
Ich habe, ( ich bin ja am testen, einen HAUFEN GLOBALER) .

Wenn ich das so richtig entnommen habe. ----

ALSO ANBRÜLLEN BRAUCHST DU MICH NICHT . Und ähm, kp was Du damit sagen willst ... . Drück Dich mal etwas verständlicher aus ...

me-S-on schrieb:

-Die char-cut and replace-Angelegenheit habe ich gestern ebenfalls scheinbar hinbekommen...... allerdings mit mehr oder weniger ANSI-C. Ich habe keine objektorientierten Methoden aus der <string> benutzt.
Könnte ich allerdings mal tun.

Ich finde OOP besser als Prozedurale. Aber das ist Ansichtssache. Arbeite einfach mal mit beiden und finde damit heraus, womit Du besser klar kommst .

me-S-on schrieb:

Nun schmiert das zwar nach dem dritten Unterordner ab( mit errorcode 6_ Invalid handle) aber das krich ich auch noch hin.

Also bei mir funktioniert die Funktion eigentlich problemlos.

me-S-on schrieb:

Diese Posts vom (D)Evil !
Echt, nomen ost omen.
Aber ihr beide könnt Euch sicher miteinander messen

Ne, ne (D)Evil ist Kollega ...er hat ja Recht, man sollte konsequent cString verwenden...glaub das hatte bei mir n internen Grund, dass ichs nicht gemacht hab. Also, wenns bei Dir passt, solltest Du auch, wie (D)Evil geschrieben hat, ne konstante Referenz auf ein cString-Objekt verwenden .

[messssson]

Danke!
Ich meinte mit:

Nein, nur pFileProc ist ein Funktionszeiger. pUserData ist ein Parameter der Funktion 'ScanFoldersForFiles'.

me-S-on schrieb:

Ok, wenn ich nun die Elemente
-TVINSERTSTRUCT
-HTREEVIEW
- char * ppath;
- char * actpath
- char *newpath
- char *dev_root
nicht alle global machen will, mache ich eine
Funktion global bekannt, welche notwendige Schritte und Variablen übernimmt, um ins TreeVew zu inserten und Images zuzufügen, mache die Suche aber in dieser SerachFolderForFile Funktion.
Dabei übergebe ich dieser einen Pointer auf die vorige Funktion, und SPARE MIR DAMIT TATSÄCHLICH GLOBALE VARIABLEN?????
Ich habe, ( ich bin ja am testen, einen HAUFEN GLOBALER) .

Wenn ich das so richtig entnommen habe. ----

ALSO ANBRÜLLEN BRAUCHST DU MICH NICHT . Und ähm, kp was Du damit sagen willst ... . Drück Dich mal etwas verständlicher aus ...

Dieszbezüglich_

Wie gesagt, das Prinzip ist vergleichbar mit einer WNDPROC. Dies hat aber nichts mit der WndProc Deines Fensters zu tun!

me-S-on schrieb:
Was übergibst du mit pData und mit pUserData?

pData ist der 2. Parameter der Funktion die Du erst definieren und deren Zeiger Du dann übergeben musst. Dies ist also kein Paremeter der Funktion 'ScanFoldersForFiles'! An pUserData kannst Du einen beliebigen Zeiger übergeben. Diese Daten stehen dann bei jedem Aufruf von dieser pFileProc-Funktion (die Du definieren musst und von meiner 'ScanFoldersForFiles'-Funktion aufgerufen wird) im 2. Parameter 'pData'. Damit verhindert man die Verwendung von globalen Variablen. Auch dieses Prinzip findet man oft in der WinAPI wieder. Vergleiche die Funktion EnumWindows, siehe letzter Parameter.
Man könnte diese Funktion auch so schreiben:

Um also meiner Suchfunktion lokaloe Variablen einer anderen Funktion zu übergeben und somit globale zu sparen...
...
ach , pFileProc ist ja die Funktion nd pUser Data deren Parameter....
:
----------------------------------
Fälschlicherweise wollte ich fragen:
Fall ich einer Funktion ein Funktion als Parameter übergebe, die NUR anhand ihres Namens den Zeiger übergibt...... habe ich dann in der Funktion, die aufruft, die Parameter des Funktionszeigers zur Verfügung, SO ALS OB sie global wären?
-----------
Know what i mean?
...
naja, ich glaube ich habe mich da verhaspelt.
---
Das ich NICHT deinen code nehme und auch nicht den , der vom OP, sollteste wissen, nur ich hänge fest, und daher muss ich forschen, weisste?
Danke, bis zum nächsten Prob!
Einen schönen Tag noch.

[messssson]

CodeFinder|logged out schrieb:

@me-S-on: Warum schreibst du so chaotisch?

nichts für ungut aber liegt am vielen kiffen dran

[me-S-on]

darum bitten, mich nicht mit irgendeinr Droge in Verbindung zu bringen, dessen Verwendungn von mir Du Dir nicht absolut sicher bist.

Da ich davon ausgehen kann dass sich (D)Evil hier gerade als ich ausgegeben hat, ist dieser post an Dich gerichtet, Evil.
Unterlasse bitte, mir Soetwas zu unterstellen, gekifft habe ich nie und anderen Krams auch nicht,solche Unterstellungen sind nicht tolerierbar und meines Erachtens auch sehr feige herübergebracht , als nichtregstrierter, der sich als jemand anderer Ausgibt.

Wie Du kleiner P.E.N.N.E:R siehst , kann ich auch labern , wie Du , Du laberst aber wie ne englische, Teatime T.U.C.K.E- also ver-p.i.s.s Dich hier aus dem Thread und gebe mit deinem S.c.h.e.i.s.s. vor Kindern in deinem (geistigen) Alter an.
Und: Du würdest jetzt sicher den Admin oder Mod dieser seite holen, DU f.ö.t.z.c.h.e.n... mach doch, aber bring mich nie wieder mit Irgendwelchen verdammten Drogen in Verbindung.

... nicht persönlich.

[messssson]

Bist du Hartz 4 Empfenger?

[DEINE_MUDDER]

Hartz vier.
Und die Kohle für Dich verdient se bei mir.
Schonmal das Wort Arbeit gehört?
So mit Mühe und Steuern?

[messssson]

[...]

messssson schrieb:

Bist du Hartz 4 Empfenger?

Empfänger

[messssson]

... schrieb:

messssson schrieb:

Bist du Hartz 4 Empfenger?

Empfänger

Thx.

[me-S-on]

wenn ich das Ganze z.B.mal so mache:

rec_search(char *path)
{
  char *found;
  char *fp;
  char *nextp;
  HANDLE fh;
  WIN32_FIND_DATA hfd;

  fh = FindFirstFile(path,&hfd);

  // Da habe ich  beim ersten Aufruf( der bei mir
  // in einer for-Schleife für jedes Laufwerk ausgeführt wird) den Jeweiligen
  // Laufwerksbuchstaben samt "\*" als Parameter, so weit so gut!!!

  do
  {
      if(!((hfd.cFileName[0]=="." && hfd.cFileName[1]== ".") && 
           (hfd.cFileName[2] == 0 || hfd.cFileName[1]=0)))
       {
          strcpy(ff,path);
          found = strstr(ff,"*");
          found = "";
          strcat(ff,hfd.cFileName);
          strcat(ff,"\\*");
          strcpy(next, ff);

          rec_search(next);

  }while(FindNextFile(hfd,&WIN32_FIND_DATA);
   findClose(fhh);
}

Also, ich glaube , ich habe es zu Hause so.( nicht ganz sicher bin...)
Ich kann nun den ersten Ordner meines Testlaufwerkes rekursiv durchsuchen und finde auch alle Ordner, die MessageBox ist auch noch in der inneren Schleife vorhanden und gibt mir immer den Übergabeparameter path aus.
Dieser wird schön verlängert und dann wird immer ein Slash und die Wildcard drangepackt.

Aber nachdem ich im ersten ordner des Laufwerkes das letzte FirstChild ( wenn ihr das versteht) gefunden habe, schmiert er ab.
Meiner Meinung nach mache ich was an der do-while falsch, oder aber ich , und das glaube ich eher, überschreibe den Pfad, der zur Rekursiven Suche gedacht ist, mit dem jeweiligen Pfad,den das letzte FirstChild empfing.
...
Das irittiert mich schon gewaltig.
Wenn ich erhlich bin, fiel mir von gestern bis heute keine geeignete Möglichkeit ein.... den Übergabeparameter abhängig zu machen von dem Rückgabewert der FindNextFile funktion, ohne den Rst zu stören.

Sehr sehr kopfzermürbend.
Hat jemand ne Erklärung, bezüglich des Konzeptes?

[Jochen Kalmbach]

@me-S-on und co: Muss das hier so ausarten!? Bitte wieder auf normale "töne" zurückfahren...

[me-S-on]

Ich entschuldige mich , aber mir soll keiner, der auch noch zu feige ist, sich zu registrieren , unterstellen, ich würde Drogen nehmen, und sich dann noch als ich ausgeben.

Ab nun kann das Niveau gerne wieder in sanften Klängen weiterlaufen.
Ist halt nur eine Verdeutlichung meines Standpunktes gewesen.

[CodeFinder]

@me-S-on:
Hm also das:

me-S-on schrieb:

schmiert er ab.

ist etwas unpräzise (Stichwort: Debugger), aber ich tippe trotzdem mal darauf, dass Du n Pufferüberlauf hast, da Du immer weiter kopierst und nie vergrößerst... aber... Warum nimmst Du nicht meine Funktion ? Die funktioniert doch ...

[me-S-on]

du auch nicht vergrösserst.
Nein, im Ernst:
Ich kann nicht einfach nur abtippen..... muss ja wissen, warum so, und nicht so , wie ich es mach...... und da ist es mir egal, wie lang es dauert.

Ich tue es immer, wenn es komplett aussichtslos erscheint...noch ist es NIHCT SO WEIT
Das war es bisher nur bei den . und .. Verzechnissen...... die mir so nie angezeigrt werden, ausser auf der Konsole.

Nun, zurück zum Thema:
Wie gesagt, du vergrösserst auch keine String-Speicherbereiche.
(Kann es sein, dass deine angewandten String-Objektmethoden dieses bereits erledigen???)

Weil,der Fehler sieht auch sehr nach einem Overflow aus:

"Regioned_Window.exe" hat einen Fehler verursachtr und wird geschlossen.
Bitte starten Sie das Programm neu.

Ich meinte auch schon, realloc und malloc irgendwie dort einzubauen...
nur, wo?
Beim Pfad, den ich erweiter.....
Debugger? Schön wärs. Dev-Cpp und der Debugger...
hinzu kommt, das mein Router irgendwelche Faxen macht.... ob der Typ, den ich hier beleidigt habe, sich auf mein System geschlichen hat und irgendwas "durcheinandergebracht" hat...... !!!
Sowas soll es ja geben.Und nun kann ihc erstmal nur ausser Arbeit mit Dir kommunizieren.

Ach:
Ähem, der sucht alels durch, ich habe einen Testordner angelegt, ihn aa genannt.
in ihm gab es aa1, in diesem aa2, in diesem aa3, in diesem aa4, in diesem aa5.
Der zweite Testordner hiess ab.
In ihm gab es ab1, in diesem ab2 und in diesem ab3.
Aber dieses Abschmieren geschieht, wenn er einen Ordner samt childern durch hat.
Bisher weiss ich noch nicht, ob FindNextFile auf die Children klappt, weil ich in die Testordner jeweil nur einen eingefügt habe und in die jeweils nur einen.
Aber wenn er mit aa fertig ist, müsste er ab checken, und genau da schmiert das Programm ab.

[Gast]

(hoffentlich ist das hier kein privat - thread )

me-S-on schrieb:

Aber nachdem ich im ersten ordner des Laufwerkes das letzte FirstChild ( wenn ihr das versteht) gefunden habe, schmiert er ab.
...
Aber dieses Abschmieren geschieht, wenn er einen Ordner samt childern durch hat.
...
Aber wenn er mit aa fertig ist, müsste er ab checken, und genau da schmiert das Programm ab.

Prüf mal die if () - Bedingung in der do-while-Schleife.

Es sieht so aus, als ob sie immer zutrifft und das Programm deshalb mit einem Stack-Overfow aussteigt.

[CodeFinder]

me-S-on schrieb:

Nein, im Ernst:
Ich kann nicht einfach nur abtippen..... muss ja wissen, warum so, und nicht so , wie ich es mach...... und da ist es mir egal, wie lang es dauert.

Ich hab Dir die Erklärungen doch schon geschrieben, was verstehst Du denn nicht ?

me-S-on schrieb:

[...]
du auch nicht vergrösserst.
[...]
Nun, zurück zum Thema:
Wie gesagt, du vergrösserst auch keine String-Speicherbereiche.
(Kann es sein, dass deine angewandten String-Objektmethoden dieses bereits erledigen???)

lol, klar ... std::string-Objekte vergrößern sich selbst, wenn es nötig ist ( dynamische Objekte).
Das ist ja (u.a.) der Vorteil von C++.

me-S-on schrieb:

Weil,der Fehler sieht auch sehr nach einem Overflow aus:

"Regioned_Window.exe" hat einen Fehler verursachtr und wird geschlossen.
Bitte starten Sie das Programm neu.

Ich meinte auch schon, realloc und malloc irgendwie dort einzubauen...
nur, wo?

Also ich bin mir ziemlich sicher, dass es ein Overflow ist... . Wenn Du nicht weißt, wie man Speicher dynamsich allkoiert (also Stichwort malloc, realloc, free, etc) dann empfehle ich Dir ein entsprechende Tutorial.

me-S-on schrieb:

Beim Pfad, den ich erweiter.....
Debugger? Schön wärs. Dev-Cpp und der Debugger...

Ähm ahja. Und ... ? Ist das mein Problem, dass Dein Debugger nicht funktioniert ? Benutze doch einen anderen Compiler bzw. eine andere IDE mit besseren/aktuellem Debugger.

merker schrieb:

(hoffentlich ist das hier kein privat - thread )

Natürlich nicht, jeder ist willkommen .

[me-S-on]

Das meinte ich ja mit: Netz geht derzeit nicht.
Sonst hätte ich mir ja die MS-VC++ express geholt.
Aber nun habe ich n Borland-Compiler aufgetrieben, samt IDE, mit dem ich früher mal unterwegs war. Das mit dem debuggen wird schon, spätestens heute!
Ich krich es noch hin.... wartet ab!

Und Malloc und realloc..... davon habe ich auch n bisschen Notizen da...
auch schonmal benutzt....
new kricht das alles einfacher hin, allerdings soll dev-cpp damit Probleme haben, die ich noch nie gemerkt habe, weil ich das damals mal bei nem Server-client-Ding benutzt habe.
Egal. Auf ein Neues.

if Bedingung?
Das n Datainame mit . oder .. anfängt und dann entweder nach einem Punkt nichts kommt , oder nach dem zweiten?
Das trifft immer zu, sicher. Hat doch jeder Ordner, dürfte doch aber kein Grund sein..... dafür, dass der abschmiert, wenn er lediglich den Parentordner ändern muss.
.
Weil, den ersten im Laufwerk geht er bis zum Ende durch, allerdings in ihm und all seinen Children auch nur die ersten.Naja. Und dann käme er entweder zum zweiten parent ordner, oder aber hätte schon folgende children seiner children und derer angezeigt. Aber nur FindFirstFile wird rekursiv ausgeführt. Die Anweisung in der do-while Bedingung nur , um den Loop auf die Children auszudehnen , nicht aber um tatsächlich weitere Dateien in einem dieser Children ( oder gar dem Parent ) zu finden.
- Aber: Danke.
Ich schätze, einige bevorzugen erstmal Sendepause.
Ich meld mich hoffentlich das nächste mal mit positiven Resultaten.
Tschüss!