1. Jeśli używam Ctrl->DTgetStr(...), to muszę na wzór "plug_defs.cpp" tworzyć nową strukturę sDTValue i ją przekazywać jako parametr czy moge po prostu używać wyniku tej funkcji jako const char*.
2. To samo pytanie jak wyżej dotyczące Ctrl->DTsetStr(...)
3. W jakiej tablicy sa zapisywane kolumny: CFG_CURGROUP, CFG_IGNORE, CFG_GROUPS, CFG_UIALLGROUPS_NOGROUP. Czy jest to DTCFG ?
4. W jakim formacie jest zwracany wynik z kolumny CFG_GROUPS, CFG_IGNORE. Czyli ogolnie listy. Wiem, że łańcuchy. Czym są jednak oddzielone poszczególne wartości.

1/2) Jak widać getStr zwraca const char*, a setStr przyjmuje const char*, więc nie wiem skąd pomysł żeby wciskać tu sDTValue Oczywiście podajesz i otrzymujesz pełnoprawne wskaźniki do łańcuchów... Pamiętaj tylko, żeby jak najszybciej skopiować ich zawartość, ponieważ kolejne wywołania DTgetStr nadpisze poprzednio zwrócone dane

3) Wszystko co zaczyna się od CFG_ jest w DTCFG (są f-cje skrótowe GETINT, GETSTR), a wszystko co ma CNT_ jest w DTCNT (znowu GETCNTI, GETCNTC)

4) Najlepiej sprawdzić samemu O ile pamiętam w obu rozdziela znak \n

1/2)
Po pierwsze zasugerowałem się użyciem plikiem "plug_defs.cpp" gdzie używa się funkcji Ctrl->DTget(...). Tu akurat mój błąd.
Inna sprawa, że w dokumentacji czytamy:

Ja tu const nie widze i stąd moje pytanie było.
Jeśli zrobie:

, to war1 nie będzie posiadał już prawdziwej wartości. Tak? I dlatego w plug_defs.cpp korzystasz z tej dodatkowej klasy? Wiec najlepiej jak bym robił tak:

Może jest jescze inny sposób, żeby nie korzystać ze stringa? Późno już i ciężko mi się myśli.

Można robić chociażby strdup, ale potem należy pamiętać o zwolnieniu wskaźnika...

Jeśli używam np:
Ctrl->DTgetStr( DTCFG, wiersz, CFG_CURGROUP );

To jaki numer wiersza muszę podać? Zero? I czy ta zasada się tyczy pozostałych przypadków.

Dlatego w plug_defs jest używane DTget() ponieważ jest to jedyna, uniwersalna f-cja "podpięta" do API. Pozostałe DTget*() po prostu z niej korzystają...

Z DTgetStr bywa różnie... Na ogół kilka kolejnych zapytań nie niszczy danych z poprzedniego, ale zawsze bezpieczniej jest użyć kopii lokalnej w postaci string. Nie wiem czemu nie chcesz go używać?

W DTCFG jest tylko jeden wiersz, a jego numerem jest 0 - więc podajesz 0. Dla konfiguracji jednak wygodniej jest używać f-cji GETSTR, GETINT itd. które robią dokładnie to co napisałeś, ale pisze się je szybciej

Czyli DTgetStr() korzysta z DTget()? Hmm to kurcze źle

Więc DTgetStr() nie nadpisuję wyników? Hmmm widze, że będe musiał wszystko przerobić na DTget() grrrr.

GETSTR jest oczywiście szybsze w pisaniu tyle, że ja pisze bibliotekę a nie wtyczke i zależy mi na innej szybkości

To w takim razie zajrzyj na svn do branches/api_0.7/konnekt . Jest już gotowa nowa, obiektowa obsługa tablic... (jej pośrednie, eksperymentalne stadium w postaci Konnekt::Tables już jest dostępne i korzysta z niego np. kUpdate. )

Nie widzę różnicy pomiędzy wywołaniem z twojej funkcji DTgetStr, które stworzy Value i przepchnie go przez DTget, a zrobieniem tego samego przez ciebie w f-cji oszczędzając jedno wywołanie... Pamiętaj, że MSVS ma całkiem zgrzebną optymalizację i najprawdopodobniej potraktuje f-cje typu GetStr i inline ...

Co do nadpisywania danych, jak już mówiłem pewności nie ma (w końcu K to program wielowątkowy), więc najlepiej rób kopie lokalne i używaj string ile wlezie...

Powiedziałbym nawet, żebyś nie używał DTget, bo w momencie gdy wyjdzie nowe API, razem ze wspierającą je wersją, f-cje jak DTgetStr, DTgetInt będą szybsze niż DTget!

Nie przesadzaj też z rozległością swojej biblioteki, API Konnekta przepisywane jest powoli na obiektowe. Najwcześniej pojawi się obsługa tablic (gotowa - Konnekt::Tables), nowa obsługa wtyczek (prawie gotowa - Konnekt::iPlugin), oraz nowa obsługa kontaktów i grup (wkrótce - iContact, oraz iContactGroup).

Oczywiście samo pisanie takiej nakładki na API ma sens, więc się przypadkiem nie zniechęcaj

No razja, zupełnie o tym nie myślałem. Dobrze, że o tym wspomniałęś.


No i git. Czyli wszsytko robię dobrze


Hehe no to mam konkurować z twoją wersją biblioteki? Hmm no nie wiem czy to ma sens. Szkoda, że nie masz jakiegoś opisu swojej bym zobaczył jak koncepcyjnie się od siebie róznia