|
|
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
если чего-то не хватает то это придётся писать. Если нет контроля за ссылками на объект а они нужны то придётся это написать самому. Логично? 8) но это никак не служит оправданием что у тебя всё падает 8))) Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 15:21 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
2Krey Kod ne shutka. Izvinite chto otluchilsia. S nedavnih por ya splu kogda vi rabotaete. Zemlia kruglaya, ponimash :)) Kod davay, "hudojnik" :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 15:59 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
авторесли чего-то не хватает то это придётся писать. Если нет контроля за ссылками на объект а они нужны то придётся это написать самому. Логично? Не понял что ты предлагаешь мне написать. Я просто не берусь реализовывать полнофункциональные классы на Фоксе вот и все. Пишу код по другому. Представления, курсорадаптеры, куча кода в формах по обработке данных этих курсоров, если конечно это нельзя сделать на сервере. Код получаеться не такой красивый какой мог бы быть. Его получаеться дольше чем могло бы быть. И так далее. Но это мои проблемы. Не хочу это сдесь обсуждать. авторно это никак не служит оправданием что у тебя всё падает Ага. Thisform.Hide на форме где нет никаких обработчиков размера и.т.д. всего того что может быть прикручено к Hide. и получаем C5. И конечно это я виноват. Это конечно следствие чего-то интересного в коде, но интерпретатор это никак не может оправдать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 16:00 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
Кстати это место в старом коде и C5 полезла только в 9-м фоксе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 16:01 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
kdanylo какой код C#-кий? Дам как домой вернусь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 16:02 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
2Krey SP1 накатывал? Если нет срочно накати, без него 9-ка вообще сплошной глюк, достаточно список пофиксенных багов посмотреть. Вроде сейчас не видно ничего подобного... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 16:05 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
Скачал, поставил. Баг все еще там. Буду искать. Сегодня пришлось отвлечься на другую работу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 17:18 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
Krey Пример: Есть форма. Есть свойство. В runtime присваиваем этому свойству ссылку на объект. Form.Close. Что происходит с формой? Часто она остаеться висеть частично разрушенной Совершенно вЕРНО!!! поддерживаю ВАС!!! давеча три дня назад у меня случилось именно такое.. форма осталась частично разрушенной, а именно наполовину разбился заголовок форму, пропали кнопки управления окном, и.. по диагонали, если можно так сказать, ну не совсем по ней снизу кусок формы тоже исчез ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 17:41 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
да, у меня (да и у многих наверна) тоже бывало по недосмотру что форма не закрывается если есть неудалённая ссылка на неё. Причина того что форма не закрывается в том что на неё есть неудалённая ссылка 8) Пример наоборот. В MS SQL можно удалить таблицу на которую ссылается процедура, сервер совершенно спокойно её позволит удалить но при запуске процедуры будет ошибка. Хотя создать процедуру со ссылкой на несуществующую таблицу сервер не даст. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 19:08 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
авторда, у меня (да и у многих наверна) тоже бывало по недосмотру что форма не закрывается если есть неудалённая ссылка на неё. Причина того что форма не закрывается в том что на неё есть неудалённая ссылка Я так и не догоняю почему многие считают это правильным. К примеру есть класс формы. Я создаю его экземпляр и устанавливаю в одно из его свойств ссылку на внешний объект с той целью что бы методы в форме использовали его или выполняли какие либо действия над ним. Далее это диалоговое окно закрываеться пользователем по нажатии кнопки "ОК". Ну скажите мне ради бога что сдесь неправильно и почему пользователь в этом случае должен наблюдать на экране развалины в форме. Или почему я как программер должен в Destroy прописывать property=null. Скажите разве я присваивал это свойство внутри какого-либо метода в форме? нет. Значит и обнулять его я при таком желании должен вне формы. Кроме того раз я закрываю форму значит мне эта ссылка не нужна. Почему объект держит форму и как такое вообще возможно? Это бред. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 20:13 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
Да я чего то недосмотрел. 1024 говорил про ссылку на форму а я про ссылку на объект внутри формы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 20:15 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
Обящанный код. Перед тем как начать тестить dot Net я некоторое время думал какое приложение мне начать писать что бы была конкретная задача но в то же время она не была связано с моей работой. Остановился на следующей задаче: Есть такая игра EVE-Online. Космическая по типу Elite (если это вам о чем нибудь говорит). В игре можно делать очень многое в том числе и торговать. Вот я решил написать прогу - помошник трейдеру в EVE. В программу вводяться предложения рынка (купля продажа товаров). Прога выдает готовый торговый маршрут: типа купить это там, это там а это там и распродать все это по дороге туда-то залетая сюда, сюда и сюда. Структура космоса: Вселенная(одна) - Регион(66) - Созвездие(780) - Солнечная система(5334) В солнечных системах есть джампгейты. всего возможных прыжков во вселенной 13892. Эта прога конечно не являеться клиентом к БД, но я такую задачу перед собой и не ставил. Как работать с данными на dotNet и так ясно. Мне интересно было получить общее представление о разработке на C#. И я его получил, чем вполне доволен. Прога еще не приняла вид законченного продукта. Надо поработать еще над главным алгоритмом и сделать пользовательский интерфейс. На данный момент я потратил на это примерно две недели рабочего времени так как работал вечерами и изредка по выходным. По объему я прикинул и повырезал все что мог без потери смысла. Оставил реализацию двух классов без реализации их внутренних мемберов и часть еще одного. Всеравно длинно получилось уж извиняйте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 23:05 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. 395. 396. 397. 398. 399. 400. 401. 402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. 426. 427. 428. 429. 430. 431. 432. 433. 434. 435. 436. 437. 438. 439. 440. 441. 442. 443. 444. 445. 446. 447. 448. 449. 450. 451. 452. 453. 454. 455. 456. 457. 458. 459. 460. 461. 462. 463. 464. 465. 466. 467. 468. 469. 470. 471. 472. 473. 474. 475. 476. 477. 478. 479. 480. 481. 482. 483. 484. 485. 486. 487. 488. 489. 490. 491. 492. 493. 494. 495. 496. 497. 498. 499. 500. 501. 502. 503. 504. 505. 506. 507. 508. 509. 510. 511. 512. 513. 514. 515. 516. 517. 518. 519. 520. 521. 522. 523. 524. 525. 526. 527. 528. 529. 530. 531. 532. 533. 534. 535. 536. 537. 538. 539. 540. 541. 542. 543. 544. 545. 546. 547. 548. 549. 550. 551. 552. 553. 554. 555. 556. 557. 558. 559. 560. 561. 562. 563. 564. 565. 566. 567. 568. 569. 570. 571. 572. 573. 574. 575. 576. 577. 578. 579. 580. 581. 582. 583. 584. 585. 586. 587. 588. 589. 590. 591. 592. 593. 594. 595. 596. 597. 598. 599. 600. 601. глумитесь наздоровье :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 23:06 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
Hi Krey! Так давай немного по порядку... 1) ЧТО ИМЕННО не устраивает в Init? - он вызывается после Load? Ну и что? Считайте что Load это "предварительная" часть конструктора - когда ещё не существует всех "внутренностей" формы - зато тут удобно готовить данные для последующей инициализации внутренних контролов. И тут можно через RETURN .F. вызвать "отмену" инстанциации объекта. Вот в NET в какой момент инициализируются "вложенные" объекты? Неужели нельзя разделить код конструктора на 2 части - ДО и ПОСЛЕ инициализации этих самых агрегированных объектов... - Init не понимает NODEFAULT - ну да, есть такая особенность - но он понимает RETURN .F. - так что никаких проблем - только запомни эту особенность и всё. - он не получает параметров из точки создания объекта? Получает! - он не может быть "перегружен"? Но это и не требуется, т.к. он может принять произвольное число параметров произвольных типов! Собственно говоря, именно из-за невозможности получить в методе параметры разных типов и/или разное их число и придуман был этот "костыль" - перегрузка методов. - написано что это event ;) Честно говоря, на заборе вообще чёрт-те что написано, а там на самом деле дрова. Давай не будет цепляться к словам. 2) Что не так с Destroy? - он при уничтожении объекта вызывается? Вызывается. - он позволяет при необходимости "разгрузить" объект? Например освободить/закрыть те ресурсы, за которыми не может следить сама среда фокса (файловый хендл, хендл ключа реестра, коннект к SQL серверу, ещё бог знает что...) Вполне позволяет. 3) Насчёт грида - да полностью согласен - это излишне усложнённый объект, и потому он крайне трудно управляем. Однако это не мешает использовать то что есть - просто не стоит пытаться полностью его перекроить - надо быть мягче, искать альтернативные варианты... Да, нельзя сделать строки разной высоты, сложно координировать позиции колонок с вложенными в них сложными контролами, в ранних версиях вообще многое приходилось через зад делать - и подсветку строки, и блокирование прокрутки некоторых строк... 4) FlexGrid я использовал в одном проекте - видел его глюки (например попробуй программно установить высоту строки :( ) но тем не менее не понимаю ТВОИХ проблем - IntelliSense с ним работает - и в ObjectBrowser он видим со всеми своими свойствами... Вполне можно обойтись и без хелпа - если методом научного тыка более привычно и удобно пользоваться... 5) Я применяю коллекции не настолько широко, чтобы страдать от того, что их элементы нетипизированны. Если мне ОЧЕНЬ НАДО, то могу написать Код: plaintext 1. 2. 3. 4. 5. методов/свойств. Причём неважно где это написано - в prg, или просто в окне кода для метода vcx/scx. Про IS в рантайме я всё равно ничего не понял. рантайм - это когда исполняется фоксовый exe - про какой там IS идёт речь, и при чём тут "неизвестный ActiveX" я не понимаю... В среде же для ActiveX-ов IS вынимает достаточно информации - в blog-е Calvin Hsia кстати писал сколько всего разного делает фокс, чтобы заработал IS для разнообразнейших объектов. Нормальное меню офисного Outlook к слову - это вообще-то тулбар а не меню. Извини, отвлекусь слегка на историю - наваяли у нас ребята программульку на NET-е, и взяли в качестве меню один из этих хвалёных компонентов (название если надо могу выяснить - чтоб не попал на это Г :) ) - оно красиво конечно, полупрозрачно, с картинками, полосками и т.п. слева ещё дерево режимов, под ним панель с "иконками" открытых окон (ну конечно список открытых окон в подменю "окна" это уже "немодно")... Правда после того как на не самой хилой тачке (и памяти там хватает и пень вроде вполне себе современный - с фоксом по крайней мере там никаких тормозов не было) открываешь всего-то с десяток форм (их всего то там штук 15), это самое "красивое меню" со всеми причиндалами начинает прорисовываться как Doom3 на первых Pentium с мегабайтной видюшкой типа S3-Trio... И в итоге вся программа через некоторое время просто падает, а комп ещё минут пять судорожно свопится... Это к вопросу о "крутых компонентах"... 6) Про "отсоединённые рекордсеты" мне опять смешно (попал пальцем в небо называется) - это в чистом виде фоксовая технология курсоров, которую MS перетянул в своё время для своего убогонького VB (ещё в доNETовские времена) и реализовал в виде ADO. Сегодня ADO конечно почти умер, но вот ADO.NET с его датасетами как ни странно опять до боли напоминает чуть приглаженный фоксовый курсорный движок. Только в фоксе можно сотворить с курсорами всё что угодно, а в ADO.NET - какие-то примитивные фильтры, реляции да аналоги calculate ... Но конечно развитие идёт. и глядишь лет через 5 тамошний курсорный движок дорастёт до уровня VFP 3.0 ;) 7) Интерфейсы - опять пустое слово. Это же просто один из способов реализации простейшей идеи в ООП - однако и без собственно интерфейсов это всё замечательно можно сделать в фоксе! Он же не типизирован, он работает на основе динамического разрешения "имён" методов/свойств!!! Я могу написать loSome.DoItBaby - и мне совсем не надо описывать "интерфейс IDoItBaby" - потом наследовать все интересующие меня классы от него, потом при вызове заниматься приведением типов (ссылки loSome) к этому самому интерфейсу... Т.е. я могу сделать всё то что позволяет получить интерфейс, но только БЕЗ него самого, и в 10 раз более коротким кодом! 8) Про Delphi vs C++ я спорить не собираюсь. У тебя своё мнение, у меня своё. Только не надо пожалуйста больше таких громогласных заявлений, что C++ это не ООП язык ;) Я не знаю ни одного серьезного (и успешного) коммерческого проекта на Delphi - куча студенческих поделок, всякие мелкие утилитки - это да, а чего-то уровня ХОТЯ БЫ MS Office - увы нету... Уже один тот факт что на C++ пишут ОС, а на Delphi нет многого стоит... Впрочем на сегодня говорить о мёртвом продукте вообще нечего - его благополучно сожрал NET. Кстати насчёт цитаты - прочитай своё ПЕРВОЕ сообщение - что там написано в предпоследнем предложении? Только дословно! И как же прикажешь тебя понимать? Ладно а теперь от слов к делу! Про проблемы со ссылками... Честное слово - без примера я ничего не могу сказать. Ибо то о чём идёт речь У МЕНЯ не происходит! Т.е. если Form1 в своём свойстве oSomeBadRef содержит ссылку на что угодно - на отдельный обособленный объект, на подобъект другой формы, на просто другую форму - это НИКОИМ образом не мешает разгрузке формы Form1 - при её разгрузке свойство автоматически уничтожится, и для соответствующего объекта уменьшится число ссылок на него - т.е. НЕТ проблемы. Т.е. создав объект и рассунув к примеру десять ссылок на него по разным объектам (утрирую) можно быть уверенным что для того что бы мне этот объект грохнуть, мне надо освободить все ссылки на него и он сам мирно ляжет, предварительно выполнив тот код что описан в его деструкторе с тильдой. Причем ссылка на созданный общий объект никоим образом не может мешать уничтожению ссылающихся на него объектов Именно так это работает и в фоксе! Никаких отличий! За исключением описанного ниже способа "убить все ссылки скопом" - не знаю есть ли такая возможность в NET, и насколько это просто там реализуется если есть. Если же в Form1 имеется скажем Textbox1 - и мы в какой-то внешний объект (свойство другой формы, или даже просто PUBLIC переменная!) поместили ссылку на этот textbox1 - то извини, но какие претензии - ты держишь ссылку на объект - а значит он не может (и не должен) уничтожаться! А т.к. он является частью более сложного "агрегата" Form1 - то и она никак не может (и не должна) уничтожаться - до тех пор пока эту ссылку не занулят. Это вполне логично и правильно! Однако! Даже в столь трудной ситуации есть "аварийный выход" - причём целых 2!!! - Можно при разгрузке формы выполнить ThisForm.RemoveObject("textbox1") - это ЯВНО уничтожит внутренний объект - при этом все ссылки на него автоматически зануляться (не nil который приводит к Access Violation в низкоуровневых языках! А простой, можно сказать тупой, фоксовый NULL - который просто вызовет при попытке обращения "через него" к объекту банальнейшую и элементарно отлавливаемую ошибку - ни о каких c005 и речи нет) - Также можно завести в самом "потенциально подвисающем" объекте метод, в котором прописать RELEASE This - это по сути тоже принудительное зануление ВСЕХ ссылок на данный объект. И опять таки ни про какие c005 речи не идёт - всё в рамках фокса и его обработчиков ошибок. Теперь насчёт "объектной мощи" - сделаешь чтоб работало просто и быстро - тотчас же пересяду на NET ;) Имеем сложный бизнес-объект (объект предметной области). Экземпляры его хранятся в реляционной СУБД (неважно какой). Имеется способ "создания" объекта из хранилища, и способ "сохранения" его в хранилище - опять же неважно КАК это реализовано - пускай это будет забота "фабрики" для этих объектов. Имеется способ поиска объекта - для простоты скажем что можно искать по любому из его хранимых атрибутов. Т.е. задали критерии - получили коллекцию загруженных объектов подходящих под этот критерий. Теперь самое интересное! Объект сложен - у него есть масса "расчётных" атрибутов (НЕ хранимых в базе) - неважно какого они рода - главное, что их рассчитывает соответствующий метод данного класса - конечно он не "из воздуха" их считает, а на основе свойств и других расчётных методов этого объекта. Т.е. получается так, что для расчёта данных атрибутов объект должен быть загружен!!! И наконец вопрос - мне нужно реализовать механизм получения коллекции объектов, в которых РАСЧЁТНЫЙ атрибут удовлетворяет заданному мной условию! Всё, абзац, приехали. Без ПОЛНОЙ загрузки ВСЕХ имеющихся объектов и последующего дурного цикла по всем этим экземплярам задача не решаема! Отличное К/С приложение получится - для работы ему надо загрузить весь массив данных в память :) Потрясающая производительность - для нахождения 2-3 подходящих элементов надо перелопатить все имеющиеся объекты! Простое решение - нарисовать ХП на сервере и обращаться при запросе к ней - но тогда на кой мне сдались вообще все эти объекты, классы и иже с ними - если логика у меня по прежнему, как и в случае с тем-же самым фоксом, находится не там где мне удобно! При этом "дублировать" расчётные методы на PL-SQL, или там T-SQL и на C# - нет уж, поищи Папу Карло в другом месте - я слишком ленив чтобы поддерживать 2 версии только из-за "объектных религиозных убеждений". Вот он - объектный подход в действии :( Конечно можно сказать что "не заточен под это NET", так не надо делать - но если так, то зачем был весь этот сыр-бор? Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 01:43 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
авторHi Krey! Так давай немного по порядку... 1) ЧТО ИМЕННО не устраивает в Init? - он вызывается после Load? Ну и что? Считайте что Load это "предварительная" часть конструктора - когда ещё не существует всех "внутренностей" формы - зато тут удобно готовить данные для последующей инициализации внутренних контролов. И тут можно через RETURN .F. вызвать "отмену" инстанциации объекта. Вот в NET в какой момент инициализируются "вложенные" объекты? Неужели нельзя разделить код конструктора на 2 части - ДО и ПОСЛЕ инициализации этих самых агрегированных объектов... - Init не понимает NODEFAULT - ну да, есть такая особенность - но он понимает RETURN .F. - так что никаких проблем - только запомни эту особенность и всё. - он не получает параметров из точки создания объекта? Получает! - он не может быть "перегружен"? Но это и не требуется, т.к. он может принять произвольное число параметров произвольных типов! Собственно говоря, именно из-за невозможности получить в методе параметры разных типов и/или разное их число и придуман был этот "костыль" - перегрузка методов. - написано что это event ;) Честно говоря, на заборе вообще чёрт-те что написано, а там на самом деле дрова. Давай не будет цепляться к словам. Собственно в Init меня как раз все устраивает. Я просто в скользь упоминул что это событие. автор2) Что не так с Destroy? - он при уничтожении объекта вызывается? Вызывается. - он позволяет при необходимости "разгрузить" объект? Например освободить/закрыть те ресурсы, за которыми не может следить сама среда фокса (файловый хендл, хендл ключа реестра, коннект к SQL серверу, ещё бог знает что...) Вполне позволяет. Дестрой как событие меня тоже устраивает. Меня не устраивает то что нет деструктора. Т.е. в некоторых случаях я не могу гарантированно убить объект (журнал еще не читал). И опять таки мой пример с формой. Form.Release дестрой отработался, а форма висит в руинах. автор4) FlexGrid я использовал в одном проекте - видел его глюки (например попробуй программно установить высоту строки :( ) но тем не менее не понимаю ТВОИХ проблем - IntelliSense с ним работает - и в ObjectBrowser он видим со всеми своими свойствами... Вполне можно обойтись и без хелпа - если методом научного тыка более привычно и удобно пользоваться... Да здесь похоже мои сведения устарели. Конкретно с FlexGrid это я плохой пример привел. В памяти моей закрепился тот факт что IntelliSence не отображал внутренности объектов - содержимых коллекций. TreeView.Nodes(1).? например. Сейчас проверил. Все отображаеться. Забираю эти слова обратно с извинениями. автор5) Я применяю коллекции не настолько широко, чтобы страдать от того, что их элементы нетипизированны. Если мне ОЧЕНЬ НАДО, то могу написать LOCAL loItem AS Form && можно и свой класс конечно тут указать, вместе с библиотекой. FOR EACH loItem IN This.colForms ? loItem. Можно. Но ведь ясно что постоянно вытаскивать типизированной переменной нужный мне метод из внутренних структур "мощного" класса что бы высветилась подсказка вызова его метода не есть гуд. Но это конечно неудобство преодолимое (к хорошему быстро привыкаешь). авторНормальное меню офисного Outlook ... Ну дык и я про это говорил. Нормально реализованный контрол еще нужно поискать, а потом еще заплатить за него. А ведь хочется. Удобно, наглядно. Если ничего не найду потрачу пару недель на его реализацию или забью на это дело. Это что касаеться Тулбара. Что то подобное FleхGrid'у конечно проще купить. авторПро "отсоединённые рекордсеты" мне опять смешно (попал пальцем в небо называется) Это я конечно ляпнул. Спросили про технологии а ведь трудно все сразу вспомнить. Все в голове когда ты с этим работаешь, а потом забываешь, что бы вспомнить когда понадобиться. автор7) Интерфейсы - опять пустое слово. Это же просто один из способов реализации простейшей идеи в ООП - однако и без собственно интерфейсов это всё замечательно можно сделать в фоксе! Он же не типизирован, он работает на основе динамического разрешения "имён" методов/свойств!!! Я могу написать loSome.DoItBaby - и мне совсем не надо описывать "интерфейс IDoItBaby" - потом наследовать все интересующие меня классы от него, потом при вызове заниматься приведением типов (ссылки loSome) к этому самому интерфейсу... Т.е. я могу сделать всё то что позволяет получить интерфейс, но только БЕЗ него самого, и в 10 раз более коротким кодом! Интерфейсы очень дельная и удобная штука. В C# варианты их использования просто необъятны... Касательно Интерфейсов и Фокса. Они там не нужны как инструмент для доп. функциональности. Согласен. Можно засовывать в какие угодно параметры, какие угодно классы и тебе за это ничего не будет после того как этот кусок кода будет отлажен. Но потом когда этого кода будет много, классов будет много и.т.д. Боюсь что даже автор будет долго втыкать в свои участки кода и долго вспоминать что он и откуда он это впихивал. Я уж не говорю про свеженанятого програмера которому придеться работать с этим проектом. Опять таки мое мнение: Фокс выплывает еще по своей функциональности потому что он интерпретатор и нетипизирован. Но это боком оборачиваеться в больших проектах. автор8) Про Delphi vs C++ я спорить не собираюсь. У тебя своё мнение, у меня своё. Только не надо пожалуйста больше таких громогласных заявлений, что C++ это не ООП язык ;) Я не знаю ни одного серьезного (и успешного) коммерческого проекта на Delphi - куча студенческих поделок, всякие мелкие утилитки - это да, а чего-то уровня ХОТЯ БЫ MS Office - увы нету... Я тоже спорить не собираюсь. Это было мое мнение. авторУже один тот факт что на C++ пишут ОС, а на Delphi нет многого стоит... Ничего этот факт не стоит. Просто так исторически сложилось еще до появления ООП как такового. авторКстати насчёт цитаты - прочитай своё ПЕРВОЕ сообщение - что там написано в предпоследнем предложении? Только дословно! И как же прикажешь тебя понимать? C# совершенно другое дело. Ну да. С# перенял все самое лучшее что я так любил в Delphi и еще это улучшил. Свойства с акцессорами например. Много чего еще. Нужно садиться, вспоминать и составлять список на бумаге, потом постить сюда. Надо? сделаю. авторТ.е. если Form1 в своём свойстве oSomeBadRef содержит ссылку на что угодно - на отдельный обособленный объект, на подобъект другой формы, на просто другую форму - это НИКОИМ образом не мешает разгрузке формы Form1 - при её разгрузке свойство автоматически уничтожится, и для соответствующего объекта уменьшится число ссылок на него - т.е. НЕТ проблемы. Если бы так было всегда я был бы наверное счастлив и еще долго бы не думал о переходе на .NET. Голословным не буду, завтра найду закоментированный кусок кода в рабочем проекте и отпостю. автор"убить все ссылки скопом" - не знаю есть ли такая возможность в NET, и насколько это просто там реализуется если есть. Если имееться в виду деструктор типа object.destroy() как в Delphi, то его там нету. Зато есть грамотный и неглючный алгоритм сборки мусора. Кстати выбрасывание объектов в пустоту (разумееться после выполнения пользовательского кода по освобождению ресурсов) в некоторых случаях упрощает программу (конкретно в случае перекрестных ссылок) и снижает кол-во ошибок. Тоже было бы и в Фоксе есле бы не было так глючно. продолжу завтра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 04:21 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
Не удержался и прочитал таки твою задачу :). Igor Korolyov придеться тебе таки переходить на .NET чему я почему то даже рад. Это ж класическое применение SQL2005 Yukon с dotNet сборками внутри :). Прям как по учебнику. У тебя есть библиотека классов (сборка) реализованная один раз в одном месте (dll). Там объектное представление твоего класса со всеми расчетными методами. И два метода LoadFromDB и SaveToDB Там же реализация коллекции этих объектов. Засовываешь эту сборку в Yukon и в клиент. С клиента вызываешь хранимку (заглушку T-SQL для dot NET метода в сборке). DotNet код на сервере заполняет коллекцию объектами, просчитываються параметры. Из процедуры клиенту возвращаються только удовлетворяющее заданным условиям подмножество загруженных и просчитанных бизнес объектов. Как и в каком виде возвращаються уже дело твоего загрузчика. Важно что клиент использует туже сборку и тебе в принципе даже не нужно париться с передачей колекции туда обратно. Можно ее передавать например в XML'е. Можно было бы твой бизнес-объект вообще dot.NET типом реализовать и хранить в базе его сериализованное представление в XML-е (готовое для передачи) + поисковые параметры в полях реляционных таблиц, но подозреваю у тебя там много данных а по скорости это решение уступит полностью реляционному. Хотя можно найти разумный компромис если уж ты такой ленивый :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 05:01 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
Hi Krey! Я всё больше и больше не понимаю что ты говоришь про деструкторы: Из хелпа (по C#) Destructors cannot be called. They are invoked automatically Т.е. это даже БОЛЕЕ ограниченное решение по сравнению с фоксовым destroy() - его НЕЛЬЗЯ вызвать - и он НЕ ПРЕДНАЗНАЧЕН для того чтобы убивать объекты - он как раз наоборот вызывается при их уничтожении, чтобы разгрузить "неуправляемые" ресурсы - т.е. идеологически он 100% аналог фоксового Destroy()! Я уже говорил, что вообще не знаю простого способа в C# "убить объект насмерть" - т.е. сделать так чтобы ВСЕ имеющиеся на него ссылки были обнулены - чтобы он мог быть подчищен "сборщиком мусора". > Ну дык и я про это говорил. Нормально реализованный контрол еще нужно > поискать, а потом еще заплатить за него... Это что касаеться Тулбара. Что > то подобное FleхGrid'у конечно проще купить. Сегодня спросил у NET-чиков во сколько они оценивают написание сравнительно простого грида (поскольку штатный грид в NET более чем убогий) - сказали пол-года (правда они никогда столь масштабных компонентов не писали, и потому могут ошибаться даже на порядок :) ). При этом привели пример DevXpress-овского грида - он существовал ещё во времена Delphi/BCB - под NET его говорят переписали с нуля - при этом по функционалу он всё ещё ЗАМЕТНО беднее старой версии - т.е. даже мощнейшая компания, которая собственно и живёт за счёт продажи этих компонент за время существования NET (я даже не заикаюсь про NET 2.0 который увидел свет чуть более полугода назад - в совершенно непригодном к употреблению бета-виде конечно :) ) не смогла полностью перенести свои старые наработки на новую платформу! Так что разговоры о том что "можно написать свои контролы" для меня по прежнему остаются пустыми - нереально это, слишком трудоёмко... >> Уже один тот факт что на C++ пишут ОС, а на Delphi нет многого стоит... > Ничего этот факт не стоит. Просто так исторически сложилось еще до > появления ООП как такового. Он стоит того, что АПИ "ближе" к С чем к Pascal. Вот и всё :) Ты видел в MSDN хоть один пример на Pascal? Я - нет :) > Кстати насчёт цитаты Чёрт, промахнулся в подсчёте точек - третье с конца имелось в виду - там НЕТ намёка на то что это именно MS VC++ 6.0 плохая среда, а С++ язык всё-же нормальный, объектный... Теперь насчёт задачи. Было сказано 1) хранятся в реляционной СУБД (неважно какой) И тут-же мне же предлагается использовать именно MS SQL 2005 - продукт сырой и весьма дорогой кстати :) Понятно почему MS так усилено пропихивает NET куда только можно - даже бесплатные урезанные версии компиляторов раздаёт - как обычно всё сводится к подсаживанию народа на Windows платформу (именно серверную! т.к. там пока ещё MS не доминирует - как-то производители SQL серверов не бегут толпами на Win) и MS SQL сервер :) 2) Без ПОЛНОЙ загрузки ВСЕХ имеющихся объектов и последующего дурного цикла по всем этим экземплярам задача не решаема! .... Потрясающая производительность - для нахождения 2-3 подходящих элементов надо перелопатить все имеющиеся объекты [quote]DotNet код на сервере заполняет коллекцию объектами[/quote] Т.е. вместо решения основной проблемы (ну воротит меня от загрузки ВСЕХ данных в коллекцию объектов - неправильно это, не должно так происходить - тогда уж лучше расчётные значения хранить постоянно, обеспечивая механизм их синхронизации/пересчёта) предлагается её по простому скрыть, перенеся процедуру создания коллекции и работы с ней на сервер - и я кстати вовсе не уверен, что на сервере будет жить именно один экземпляр подобной "сборки" - т.е. что не создастся для каждого коннекта (ну или не для каждого, но просто "не один") свой процесс, не загрузится в каждый процесс полностью вся коллекция объектов... А значит тут-же я должен начать писать именно серверной приложение - менеджер объектов, которое будет реализовывать как минимум единый репозиторий подобных объектов, заниматься их "предоставлением" клиентам, получить обратно и обновлять хранящиеся у себя экземпляры - т.е. по сути нужно делать объектную СУБД... IMHO затраты на такое решение несоизмеримы с получаемыми преимуществами... Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 02:15 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
авторЯ всё больше и больше не понимаю что ты говоришь про деструкторы: Из хелпа (по C#) Destructors cannot be called. They are invoked automatically Т.е. это даже БОЛЕЕ ограниченное решение по сравнению с фоксовым destroy() - его НЕЛЬЗЯ вызвать - и он НЕ ПРЕДНАЗНАЧЕН для того чтобы убивать объекты - он как раз наоборот вызывается при их уничтожении, чтобы разгрузить "неуправляемые" ресурсы - т.е. идеологически он 100% аналог фоксового Destroy()! Я уже говорил, что вообще не знаю простого способа в C# "убить объект насмерть" - т.е. сделать так чтобы ВСЕ имеющиеся на него ссылки были обнулены - чтобы он мог быть подчищен "сборщиком мусора". Цитирую сам себя: авторЕсли имееться в виду деструктор типа object.destroy() как в Delphi, то его там нету. Зато есть грамотный и неглючный алгоритм сборки мусора. Кстати выбрасывание объектов в пустоту (разумееться после выполнения пользовательского кода по освобождению ресурсов) в некоторых случаях упрощает программу (конкретно в случае перекрестных ссылок) и снижает кол-во ошибок. Тоже было бы и в Фоксе есле бы не было так глючно. Насчет багов деструктора в Фоксе, то быстро сделать пример не получилось. Появиться у меня время сделаю пример и запостю. авторСегодня спросил у NET-чиков во сколько они оценивают написание сравнительно простого грида (поскольку штатный грид в NET более чем убогий) - сказали пол-года (правда они никогда столь масштабных компонентов не писали, и потому могут ошибаться даже на порядок :) ). При этом привели пример DevXpress-овского грида - он существовал ещё во времена Delphi/BCB - под NET его говорят переписали с нуля - при этом по функционалу он всё ещё ЗАМЕТНО беднее старой версии - т.е. даже мощнейшая компания, которая собственно и живёт за счёт продажи этих компонент за время существования NET (я даже не заикаюсь про NET 2.0 который увидел свет чуть более полугода назад - в совершенно непригодном к употреблению бета-виде конечно :) ) не смогла полностью перенести свои старые наработки на новую платформу! Так что разговоры о том что "можно написать свои контролы" для меня по прежнему остаются пустыми - нереально это, слишком трудоёмко... И снова себя цитирую: автор Ну дык и я про это говорил. Нормально реализованный контрол еще нужно поискать, а потом еще заплатить за него... Это что касаеться Тулбара. Что то подобное FleхGrid'у конечно проще купить. авторЧёрт, промахнулся в подсчёте точек - третье с конца имелось в виду - там НЕТ намёка на то что это именно MS VC++ 6.0 плохая среда, а С++ язык всё-же нормальный, объектный... Ну я имел ввиду MS VC++ 6.0, правда не написал об этом. Я знаком только с двумя реализациями объектного C: MS и Borlad (CBuilder). Если забыть конечно про то что CBuilder на самом деле никакой не C а делфи с C-шным синтаксисом, то вполне хорошо объектный С получился :-). Теперь насчёт задачи. Если параметры по которым нужно делать отбор не храняться в БД, то понятно, чтобы вернуть отфильтрованный по этим параметрам набор данных, нужно сначала их просчитать для всего набора данных, по другому никак. Уверен что совершенно не принципиально в каком виде будет реализован алгоритм расчета: в виде ХП или в NET сборке, главное что бы он выполнялся на сервере. авторну воротит меня от загрузки ВСЕХ данных в коллекцию объектов - неправильно это, не должно так происходить - тогда уж лучше расчётные значения хранить постоянно, обеспечивая механизм их синхронизации/пересчёта) Да так будет лучше, но тогда условие задачи меняеться. авторТ.е. вместо решения основной проблемы предлагается её по простому скрыть, перенеся процедуру создания коллекции и работы с ней на сервер Но ведь без полного расчета параметров задача не решаеться. А вот в коллекции это будет происходить, или нет здесь нет принципиальной разницы. Просто так будет удобней. Создастся объект, установяться его свойства данными из БД, просчитаються расчитываемые свойства. Если ты будешь реализовывать это через native XP, тогда действительно придеться дублировать код расчета (по условиям задачи я понял что код расчета в клиенте обязательно должен присутствовать), что не есть гуд. автори я кстати вовсе не уверен, что на сервере будет жить именно один экземпляр подобной "сборки" - т.е. что не создастся для каждого коннекта (ну или не для каждого, но просто "не один") свой процесс, не загрузится в каждый процесс полностью вся коллекция объектов... Я уверен что будет не один экземпляр, ведь NET код будет запускаться из разных сессий. Но ведь если ты реализуешь расчетные методы в native ХП будет тоже самое. авторА значит тут-же я должен начать писать именно серверной приложение - менеджер объектов, которое будет реализовывать как минимум единый репозиторий подобных объектов, заниматься их "предоставлением" клиентам, получить обратно и обновлять хранящиеся у себя экземпляры - т.е. по сути нужно делать объектную СУБД... IMHO затраты на такое решение несоизмеримы с получаемыми преимуществами... Незачем изобретать велосипед. Храни все параметры в БД и синхронизируй их при изменениях. Но даже и в этом случае используя Yukon и сборки можно реализовать эту задачу лучше. Главное что код твоего бизнес-объекта будет один. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 14:11 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
согласен. Незачем изобретать велосипед. Есть база данных, есть SQL. Совать данные из таблиц в объекты незачем т.к. работать с данными можно непосредственно на SQL, он для этого и предназначен --- велосипед это "Храни все параметры в БД и синхронизируй их при изменениях" Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 14:38 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
1024 , смотря на каком уровне ты живешь. Если дошел до деклатаривного описания функций системы, "Совать данные из таблиц в объекты " - есть за чем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 14:50 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
о какие слова! 8) не факт что тот кто "дошел до деклатаривного описания функций системы" знает на должном уровне скл. Мож ему (конкретно ему) так удобней Это вам в топик по объектным субд надо Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 15:02 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
а я сую и еще как сую да еще и пинаю потом, чтобы потом сами подсовывались и подпинывались и еще за хвост целую семейку тащили и знали где и как жить и чего делать шучу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 15:20 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
Hi alex11100! Это ты про отложенную загрузку (Lazy Read) так завернул? Тоже кстати интересная проблема - если НЕ реализовывать отложенную загрузку, то чисто объектная модель (в которой связи реализованы как объектные ссылки) будет норовить при создании всего одного махонького объекта вынуть пол-базы :) Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 02:03 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
Hi Krey! > Зато есть грамотный и неглючный алгоритм сборки мусора Ну как бы так помягче сказать... Не верю я что он безглючный. В фоксе эту систему дай боже 10 лет реализуют и до сих пор в каких-то случаях (правда по моему опыту - в весьма и весьма редких случаях) он даёт сбои и не выгружает либо объект, либо (что кстати чащё случается) описание класса (оно тоже сидит в памяти в каком-то хитром виде)... А в NET значится вот так взяли и за пару лет сделали идеал :) > Кстати выбрасывание объектов в пустоту (разумееться после выполнения > пользовательского кода по освобождению ресурсов) в некоторых случаях > упрощает программу (конкретно в случае перекрестных ссылок) и снижает > кол-во ошибок. Если в А есть ссылка на Б, а в Б есть ссылка на А, то к чему привидёт "выбрасывание в пустоту" - т.е. уничтожение других (не этих "взаимных") ссылок? Это очень сложная проблема (поскольку я то привёл самый что ни на есть простой вариант - реально всё может быть гораздо более запутано). И ты утверждаешь что в этой системе в принципе нет и не может быть ошибок? Очень сомневаюсь... > Если забыть конечно про то что CBuilder на самом деле никакой не C а делфи > с C-шным синтаксисом Про это я и говорил :) Не натуральный он С++ а мутант жуткий :( Если бы не удобный интерфейс (который у MS вплоть до последнего времени был лишь в VB и VFP ;) ) то умер бы он так и не родившись. > Теперь насчёт задачи. Да, ты конечно прав - но лишь в том что расчёт должен вестись на сервере :) Кстати другой вариант - это построение специального вида "вывернутых" функций, которые могут хотя-бы оценочно перевести искомый расчетный параметр в набор "подходящих" исходных параметров - с тем чтобы подставить этот набор в качестве условий отбора и уже на результатной выборке воспользоваться "прямым" алгоритмом и отсеять те записи что всё-же не подходят... Конечно надо признать что не всякая функция может быть таким образом вывернута... Но например f(a,b) = a+b или f(a) = abs(a) - может :) Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 02:03 |
|
||
|
VFP9.0 - It sounds good!
|
|||
|---|---|---|---|
|
#18+
1. Оба языка, Pascal и C были созданы на базе языка Алгол. 2. Pascal появился раньше в Европе, C позже и в Америке. 3. На языке Pascal как и C были написаны(!) Операционные Системы. 4. Процессор IBM PC - создавался фирмой IBM как Pascal машина, Pascal ориентированный процессор. 5. Язык Object Oriented Pascal (OOP) появился намного раньше, чем C++. 6. Windows 95, Windows 98 НАПИСАНЫ на PASCAL. 7. Библиотеки в ранних версиях MS VC++ были написаны на PASCAL. 8. Язык C# был разработан для MS компанией Borland. И у компании Borland есть своя версия языка C#. 9. Язык Pascal ОЧЕНЬ приближен к HardWare и позволяет делать вставки на ассемблере. Смотри пункт 3. Все это жесткие и обще известные факты, очень легко проверяемые ... P.S. OS для MAC PC писалась на Pascal. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2008, 14:37 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=33436958&tid=1587808]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
47ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 313ms |

| 0 / 0 |
