Új hozzászólás Aktív témák

• #5 urandom0 őstag jattila48 #4

  Új Válasz 2022-05-02 22:09:42 #5

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  urandom0

  őstag

  LOGOUT blog

  válasz jattila48 #4 üzenetére

  Hát nem tudom mennyire van értelme úgy általában asztali fejlesztéssel foglalkozni. Készülnek még új asztali appok? Lehet őket monetizálni? Ha írsz egy asztali appot, mennyi pénzt kell beleölni abba, hogy egyáltalán megtalálják?
  Szerintem manapság egyrészt webre, másrészt (és főleg) mobilokra megy a fejlesztés.

• #4 jattila48 aktív tag jattila48 #3

  Új Válasz 2022-01-18 20:45:53 #4

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jattila48

  aktív tag

  válasz jattila48 #3 üzenetére

  Hát, úgy látom nem igazán érdekel senkit a Windows programozás, de legalábbis a felvetett probléma (hiba) biztosan nem. Közben kiderült, hogy a Windows 7/10 alatt a Visual Studio common control 5.x verzióval linkeli a programot, ez okozza a fent leírt hibát, holott elvileg így is jól kéne működnie. Külön manifest-ben, vagy #pragma-ban kell kérni, hogy a 6.0-ás common control-lal linkeljen, és úgy már jó lesz. Egyéb hibák is vannak az 5.x verzióval:
  pl. a listview control tooltip controljának küldött WM_TIMER üzenetek elkezdenek feltartóztathatatlanul ömleni, ha a listview "üres" (ahol nincs list item) területére clickkelünk. Valószínűleg a tooltip üzenet kezelő függvényének a WM_TIMER üzenet(ek) kezelése után kill-elni kéne a timert, de ezt nem teszi meg.
  A treeview controll "félig takart" item-én csak akkor jelenik meg a tooltip, ha előzőleg a kurzor szintén olyan itemen volt, amin meg kellet volna jelennie a tooltipnek, és közvetlenül erről mozdítottuk át a másik itemre.
  Mindezek a hibák 6.0-ás verzióval nem jelentkeznek. A kérdésem az (persze csak költői), hogy régebbi verziójú windowsokon (ahol esetleg még nem is volt 6.0-ás common control) is fent álltak ezek a hibák, vagy csak a Windows 7/10 verziókkal együtt van ez, vagy esetleg valamit rosszul linkelek, rosszul állítok be a projectben?
  Windows 7-en a 6.0-ás common control elég jól néz ki, de Windows 10-en pocsék. Nagyon zavaró pl., hogy a listview control header-je (listview repot módban), (ahová az oszlopok nevét szokták írni) fehér, alig különül el a kliens területtől. A tooltipek szintén egyszerű fehér színűek, szemben a Windows 7 metál szürke áttűnős tooltipjével, vagy az 5.x sárga tooltipjével. Esetleg, ha valaki meg tudná mondani, hogy lehet Windows 10-en Windows 7 megjelenésű controlokat használni, annak örülnék.

• #3 jattila48 aktív tag jattila48 #2

  Új Válasz 2021-11-24 23:17:38 #3

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jattila48

  aktív tag

  válasz jattila48 #2 üzenetére

  Na most már az az egyetlen kép is eltűnt, amit sikerült feltölteni. Remélem így is érthető a kérdés. A "Public" item a directory fa legalsó iteme volt, és kezdetben a fa elfért az ablakban, függőleges scrollbar megjelenése nélkül.

• #2 jattila48 aktív tag

  Új Válasz 2021-11-24 23:12:14 #2

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jattila48

  aktív tag

  És akkor lenne is egy kérdésem: A TreeView control-t használom API fv.-ekkel. Szerintem hibás a TreeView megvalósítása. Egy directory fát jelenítek meg az ablakban, ami ha elfér az ablakban, akkor függőleges scrollbar nélkül jelenik meg:
  Ez idág OK. Ha expandálom a legalsó "Public" itemet, akkor az abalak scrollozódik, és megjelenik a függőleges scrollbar, lehúzva az ablak aljára: ez is OK
  (Közben valamiért nem tudok képet feltölteni)
  Felhúzom a scrollbart, akkor az 1. képhez hasonló a megjelenés, de a "Public" item előtt '-' jel áll, jelezve, hogy az item még expandált. Ez is OK.
  Na most ha collapse-elem a "Public" itemet, akkor a scrollbar nem tűnik el (holott el kéne), de nem is használható. Vagyis valójában megszűnik, de az ablak nem lesz megfelelően frissítve. Ha a desktopon kívülre viszem az ablakot és visszahúzom, akkor frissül az ablak, és már nem jelenik meg a scrollbar.
  Próbáltam UpdateWindow-val frissíteni az ablakot, amitől sokkal jobb lett a helyzet, de a hiba nem szűnt meg teljesen. Néha még így is fennáll.
  Találkoztatok már ezzel? Hogy lehetne megoldani? Én rontok el valamit, vagy tényleg "gyárilag" hibás a TreeView control?

• #1 jattila48 aktív tag

  Új Válasz 2021-11-24 22:30:30 #1

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jattila48

  aktív tag

  Főleg Windows API programozással kapcsolatos hozzászólások jöhetnének ide, de elfér az MFC, WPF, XAML, .Net, COM, vagyis minden technológia, ami a Windows GUI programozását, és a Windows operációs rendszer belső működését érinti. Elsősorban a Windows operációs rendszer rejtelmeit, és a rendszer által nyújtott szolgáltatásokat/technológiákat tárgyalhatnánk programozási szempontból. A használt programozási nyelv kevésbé érdekes, az azokkal kapcsolatos kérdésekre külön topikok vannak. Mivel a rendszer mélyebb működését szeretnénk megérteni, ezért leginkább C/C++ nyelven írt kérdéseket és válaszokat várok. Persze lehet más is (pl. Python, C#, Visual Basic, VBA, stb.), de a magas szintű könyvtárak használatára vonatkozóan érdemes más topikot felkeresni.

Új hozzászólás Aktív témák