Borland builder problem

[ ShadowMind @ 17.11.2008. 18:48 ] @

Zanima me da li je ikako moguce da se u Builder-u ikako prebaci pokazivac iz glavne forme u dijalog ili obrnuto, svejedno mi je, ako neko moze da mi pomogne bio bih mu veoma zahvalan. Inace koristim Borland C++ Builder 6.

[ X Files @ 17.11.2008. 18:58 ] @

Citat:

da li je ikako moguce da se u Builder-u ikako prebaci pokazivac iz glavne forme u dijalog ili obrnuto

Pokazivači na glavnu formu u C++ Builderu su po defaultu globalni, to je ovaj deo:
--- Unit1.cpp ---

Code:

// ...
TForm1 *Form1;
// ...

--- Unit1.h ---

Code:

// ...
extern PACKAGE TForm1 *Form1;
// ...

Ako imaš neku drugu formu (Form2/Unit2.cpp), imaš pokazivač na glavnu formu uvek dostupan, samo dodaj header glavne forme:

--- Unit2.cpp ---

Code:

// ...
#include "Unit1.h"
// ...
void __fastcall TForm2::Button1Click(TObject *Sender)
{
Form1->Caption = "Novi naslov glavne forme";
}
// ...

...ili čak bez #include "Unit1.h", samo:

Code:

extern TForm *Form1;

[ ShadowMind @ 17.11.2008. 19:08 ] @

problem je sto ja u .cpp glavne forme imam globalnu promenjivu kojoj iz dijaloga ne mogu pristupiti. Pa sam mislio ako mogu njen pokazivac da prosledim u dijalog.

[ X Files @ 17.11.2008. 19:17 ] @

Ako sam razumeo, ti imaš globalnu promenljivu u glavnoj formi, i to u CPP fajlu:
--- Unit1.cpp ---

Code:

int Globalna;

Ako je to, onda ti extern završava posao:
--- Unit2.cpp ---

Code:

extern int Globalna;

... pa joj pristupaj do mile volje (ne treba ti pokazivac na nju, dovoljno je extern).

Ipak, razmisli još jednom o dizajnu, odnosno da li je ta globalna promeljiva baš morala da bude globalna, a ne deo neke klase.

[ ShadowMind @ 17.11.2008. 21:53 ] @

Sad sam pokusao sa extern, proslo je kompajliranje i ok, ali kada pristupam nekim metodama te globalne promenjive u dijalogu izbacuje mi neku gresku i ne radi dobro, a kad pristupam ostalim metodama koje funcionisu kao da pristupa nekom drugom objektu a ne onom iz glave forme o.O

Ta globalna promenjiva je u stvari objekat klase koja sadrzi u sebi pet mapa koje su mi kontejneri u koje smestam objekte nekih mojih klasa, tako da sam trebao objekat koji ce mi ziveti tokom izvrsavanja celog programa pa sam ga stavio kao globalni.

[ kiklop74 @ 19.11.2008. 00:32 ] @

Onda je mnogo zdravija ideja da koristis singleton klasu. nesto kao ovo

Code:

//singleton.h
#ifndef SINGLETON_HH
#define SINGLETON_HH

#include <string>
#include <map>

typedef std::map<std::string, std::string> stringMap;

struct singleton {
  stringMap map1;
  stringMap map2;
  stringMap map3;
  stringMap map4;
  stringMap map5;

  static singleton& instance(void) {
       static singleton inst;
       return inst;
  }

private:
  singleton(void) {}
  ~singleton(void) {}
  singleton(singleton const&);
  singleton& operator=(singleton const&);
};

#endif /* SINGLETON_HH */

Pa zatim negde u programu inicijalizujes singleton (prvi poziv ga inicijalizuje i instanca se gasi garantovano pri zatvaranju programa). Npr. dobro mesto bi bio konstruktor forme koja se automatski kreira ili cak Winmain.

Code:

//inicijalizacija
singleton::instance();

//pristup nekoj od mapa
singleton::instance().map1.insert(std::make_pair("aa","bb"));

[ deerbeer @ 19.11.2008. 09:45 ] @

Da singleton je zdravije resenje , mozda recimo ovako :

Code:

#include <afxmt.h>
using namespace std ;

template <class T>
class Singleton
{
protected  :
   Singleton<T>(){}
  ~Singleton<T>() {}

public :
   static int refCount;
   static CCriticalSection m_cs ;
   static auto_ptr<T> _instance ;

public:
   static T* getInstance()
   {
        m_cs.Lock() ;

        if (_instance.get() == 0) {
              _instance = auto_ptr<T>(new T);
         }
         refCount++ ;
         m_cs.Unlock();
         return _instance.get();
     }

    // ovo je opciiono ako zeli u nekom treuntku da radi delete  mada ne treba zbog auto_ptr-a
     static void Delete () {
        T* instance =  _instance.release() ;
        delete instance ;
        instance = 0;

    }

};
template <class T> int Singleton<T>::refCount = 0 ;
template <class T> CCriticalSection Singleton<T>::m_cs ;
template <class T> auto_ptr<T> Singleton<T>::_instance;

thread-safe templejt singleton ,
s tim sto CCriticalSection (signalizacija za thread) moze da zameni sa nekom drugom klasom koja odgovara njegovom razvojnom okruzenju ..

[ kiklop74 @ 19.11.2008. 11:32 ] @

Citat:

deerbeer: Da singleton je zdravije resenje , mozda recimo ovako

Tvoj primer nije upotrebljiv u njegovom slucaju jer covek koristi BCB, a uz BCB ne dolazi MFC pa samim time ni CCriticalSection.

S druge strane ne mislim da ce mu trebati thread safe singleton jer ako se radi o standardnoj GUI aplikaciji sa verovatnocom od 90% mozemo da pretpostavimo da nece biti vise threadova, zato sam namerno poslao ovaj barebone primer.

Ako ipak zatreba thread safe singleton onda mozda vredi pogledati i Loki (http://loki-lib.sourceforge.net/)

[ deerbeer @ 19.11.2008. 12:39 ] @

Citat:

Tvoj primer nije upotrebljiv u njegovom slucaju jer covek koristi BCB, a uz BCB ne dolazi MFC pa samim time ni CCriticalSection.

Jednostavno zameni CCriticalSection sa CRITICAL_SECTION strukturom
a Lock i Unlock zameni EnterCriticalSection i LeaveCriticalSection api pozivima ...
a to sve moze da wrapuje u jednu malu klasu ..

Code:

class CSync
{
public:
  CSync() { InitializeCriticalSection(&m_CriticalSection); }
  ~CSync() { DeleteCriticalSection(&m_CriticalSection); }
  void Acquire() { EnterCriticalSection(&m_CriticalSection); }
  void Release() { LeaveCriticalSection(&m_CriticalSection); }

private:
  CRITICAL_SECTION m_CriticalSection;
};

class CLock
{
public:
  CLock(CSync &refSync) : m_refSync(refSync) {  }
  ~CLock() {}

  void Lock() { m_refSync.Acquire(); }
  void Unlock() { m_refSync.Release(); }

private:
  CSync &m_refSync;

  CLock(const CLock& refcSource);
  CLock&operator=(const CLock& refcSource);

};

Ne vidim sto ne bi ovo radilo po Borlandom ..

Citat:

S druge strane ne mislim da ce mu trebati thread safe singleton jer ako se radi o standardnoj GUI aplikaciji sa verovatnocom od 90% mozemo da pretpostavimo da nece biti vise threadova, zato sam namerno poslao ovaj barebone primer.

Naravno ..ne mislim da mu sad treba zbog tredova ..vec sam samo bacio akcenat
na template jer je u principu "uiniverzalan" za svaki tip ...
Ovako treba da ponovo pise singleton za svaku klasu posebno, ako bude imao potrebu ...

Pozdrav!!