Problem mit MouseUp im StringGrid

wolf_10

Hallo,
ich habe ein kleines problem mit dem MouseUp-Ereignis für ein StringGrid
meine Routine sieht so aus:

void __fastcall TForm1::StringGrid1MouseUp(TObject *Sender, TMouseButton Button, TShiftState Shift, int X, int Y)
{
    if(!Entrys.empty())
    {
 		int col=StringGrid1->Col;
 		int row=StringGrid1->Row;
 		if(col ==2)
 		{
            AnsiString temp= "##########";
            StringGrid1->Cells[col][row]=temp;
 		}
    }
}

Nun steht in der Zelle nicht '###########' sondern irgendein Textmüll.
Weiß jemand was ich falsch mache????

Jansen

Das Problem ist mit deinen Angaben nicht nachvollziehbar, der Fehler liegt vermutlich in einem anderen Programmteil.

wolf_10

Also ich habs gefunden,

das Problem lag am AnsiString temp
trotz Zuweisung von

AnsiString temp ="##########";

stand irgendwelcher Müll drin.
Nachdem ich 'temp' dan global deklariert habe ging es dann (sehr seltsam oder???)

Jansen

Das deutet weiterhin auf einen Fehler an anderer Stelle im Programm hin. Der von dir gezeigte Codeabschnitt ansich funktioniert problemlos, was du anhand eines Minimalprojektes leicht überprüfen kannst.

Übrigens: der Plural von entry lautet entries ...

wolf_10

Jansen schrieb:

Übrigens: der Plural von entry lautet entries ...

Danke für den Tip, im Eifer des Gefechtes halt

Es scheint ein grundsätzliches Problem mit dem AnsiString zugeben, da es an verschiedenen anderen Stellen auch zu diesem seltsamen Phenomän kommt.

Es läßt sich schwer nachvollziehen weil es von 10 mal, 9 mal klappt und einmal eben irgendwelche Grütze im String steht.

Dafür gibt's den Debugger... Haltepunkt setzen und prüfen welcher Wert wohin geschrieben wird.

Alexander Kempf

wolf_10 schrieb:

Es scheint ein grundsätzliches Problem mit dem AnsiString zugeben

Das wird Borland wahrscheinlich nicht zugeben

wolf_10 schrieb:

da es an verschiedenen anderen Stellen auch zu diesem seltsamen Phenomän kommt.

Es läßt sich schwer nachvollziehen weil es von 10 mal, 9 mal klappt und einmal eben irgendwelche Grütze im String steht.

Also, ich kann dieses Phänomen nirgendwo bei mir feststellen. Und wenn es wirklich in 10% der Fälle
nicht klappen würde, wäre wohl zwischenzeitlich längst ein Aufschrei durch die Borland-Gemeinde
gegangen.
=> Der Tipp mit dem Debugger von Joe_M. ist wahrscheinlich nicht der schlechteste.

Gruß,

Alexander

wolf_10

Nein ich meinte nicht das es ein grundsätzliches Problem von Borland ist, sondern von meinem Prog.

Natürlich habe ich schon mehrmals mit Breakpoints kontrolliert, aber ich finde nix.
Wenn ich ne Zuweisung mache und ne Zeile darunter den String wieder auslese und dann irgendwas anderes drin steht, na dann weiß ich nicht wie ich da noch debuggen soll.

Noch ein kleines Beispiel:

SaveDialog1->Execute();
    AnsiString filename= SaveDialog1->FileName;
    if(!filename.IsEmpty())
    {
	myIOHelper.Entrys = Entrys;
    	myIOHelper.SaveUserListAs(filename);
    }

Nun sollte man meinen das in 'filename' der Dateiname steht oder??
Tut er aber nicht immer, also da weiß ich echt nicht mehr weiter

Oder:

if(MessageDlg("Möchten Sie die Änderungen noch speichern?", mtConfirmation , TMsgDlgButtons() << mbYes << mbNo , 0)==mrYes)
     	{
          	BtnFileSave->Click();
        }

Ich dachte auch, das nun ne MessageBox kommt mit der entsprechenden Meldung, iss aber nicht so, es kommt nur Textmüll.

Zumindest gibt's ne kleine Regelmäßigkeit, der Textschrott ist immer der gleiche, was ja heißt das der Zeiger immer auf ne falsche Adresse zeigt.

wolf_10 schrieb:

Es scheint ein grundsätzliches Problem mit dem AnsiString zugeben, da es an verschiedenen anderen Stellen auch zu diesem seltsamen Phenomän kommt.

Also ich kann mir beim besten Willen nicht vorstellen, dass AnsiString der Übeltäter ist. Das ist eine der Klassen die bei mir - trotz intensiver Verwendung - überhaupt keine Probleme bereitet.

wolf_10 schrieb:

Es läßt sich schwer nachvollziehen weil es von 10 mal, 9 mal klappt und einmal eben irgendwelche Grütze im String steht.

Und das klingt dann SEHR nach einem Problem in Deinem Source, allerdings an einer Stelle, die Du hier nicht gepostet hast...

Alexander Kempf

Mal abgesehen davon, daß man SaveDialog vielleicht besser so

if (SaveDialog1->Execute())
    {
      AnsiString filename= SaveDialog1->FileName;
      if(!filename.IsEmpty())
      {
	  myIOHelper.Entrys = Entrys;
    	  myIOHelper.SaveUserListAs(filename);
      }
    }

verwenden sollte, kann ich allerdings auch keinen offensichtlichen Fehler erkennen. Bist
Du Dir sicher, daß Du auch immer vor dem Kompilieren abspeicherst? Vielleicht hilft es ja auch
das Projekt neu zu erzeugen (über Projekt|<Projekt> erzeugen). Und dann gibt es ja noch die
anderen bekannten Tips wie *.tds-Datei löschen, *.obj-Dateien löschen etc.

Gruß,

Alexander

Hast Du irgendwelche Fremdkomponenten installiert? Hast Du irgendwo using namespace verwendet?
Ist es möglich das Projekt mal irgendwo zum Download bereitzustellen?

wolf_10

Joe_M. schrieb:

Hast Du irgendwelche Fremdkomponenten installiert? Hast Du irgendwo using namespace verwendet?
Ist es möglich das Projekt mal irgendwo zum Download bereitzustellen?

Ja ich hab Fremdkomponenten drin.
ne kein using namespace.
Ne Download ist noch keiner verfügbar.

Ist schon seltsam, ich arbeite im Projekt mit std::Vector die ne Struktur verwalten, diese wiederrum besteht aus mehreren char's.
Nun kopiere ich mit strcpy entsprechend Strings in die Struktur um sie dann in den Vector zu hängen

User_Entry test;
strcpy(test.Beschreibung, txtBeschreibung->Text.c_str());

und ich denke mal das das Prog damit nicht zurecht kommt, obwohl es ansonsten einwandfrei funzt, un beim debuggen auch alles klar geht.

Mich wundert es nur das es dann an verschiedenen Stellen im Programm Probleme bei der Textausgabe gibt.

junix

Zeig mal die Strukturdeklaration. Ausserdem sollte man von der Verwendung von strcpy absehen und es durch strncpy ersetzen.

-junix

wolf_10

junix schrieb:

Ausserdem sollte man von der Verwendung von strcpy absehen und es durch strncpy ersetzen.

-junix

Und warum???
Ich hatte damit noch nie Probleme

struct User_Entry
{
  char Beschreibung[35];
  char Benutzername[35];
  char Passwort[35];
  char URL[55];
  char Kategorie[35];
};

junix

Weil du so z.B. in txtBeschreibung einen beliebig langen String eingeben kannst und dieser dann zu einem klassischen Buffer Overflow führen kann. Mit strncpy kann dir das nie passieren. strcpy ist eine der häufigsten Ursachen für Sicherheitslücken. Daher gleich mal abgewöhnen.

Dazu kommt, dass bei nicht kontrollierter Beschreibung eines feststehenden Puffers es z.B. auch zu folgenden Effekten kommen kann:

Mich wundert es nur das es dann an verschiedenen Stellen im Programm Probleme bei der Textausgabe gibt.

... und das sind noch die harmlosen...

wolf_10

junix schrieb:

Weil du so z.B. in txtBeschreibung einen beliebig langen String eingeben kannst und dieser dann zu einem klassischen Buffer Overflow führen kann. Mit strncpy kann dir das nie passieren. strcpy ist eine der häufigsten Ursachen für Sicherheitslücken. Daher gleich mal abgewöhnen.

Dazu kommt, dass bei nicht kontrollierter Beschreibung eines feststehenden Puffers es z.B. auch zu folgenden Effekten kommen kann:

Mich wundert es nur das es dann an verschiedenen Stellen im Programm Probleme bei der Textausgabe gibt.

... und das sind noch die harmlosen...

OK, danke mal für den Tip
dann werde ich mal umbauen und schauen obs dann geht

wolf_10

Jo ich habs gefunden,

echt tricky und zwar war es tatsächlich ein strcpy, nämlich genau der dessen Textmüll immer angezeigt wurde.
Ts, ts, ts sowas hab ich auch noch nicht gesehen.

Vielen Dank noch mal an alle für die Tips

Braunstein

Wobei man auch bei strncpy aufpassen muss, da
Zitat Borland Hilfe zu strncpy

Wenn src mehr als maxlen Zeichen umfaßt, bleibt der nach dest kopierte String ohne abschließendes Nullzeichen.

wolf_10

Würde heißen, man sollte auf jeden Fall ein Zeichen aus dem String kappen falls der zu lang wäre.

Braunstein

oder '\0' an das letzte mögliche Zeichen zuweisen (in dest).

wolf_10

Der Text kommt aus einem Edit-Feld da stell ich MaxLength halt auf 34 bzw 54 dann sollte das passen