чувак, ты проспись пойди лучше. Ты или сишарп впервые позавчера увидел, или тебе пора отдохнуть, потому что сейчас я вижу что ты в блоке try только пишешь в лог-файл, а должен по идее пытаться выполнить какое-либо действие с файлом. Сейчас исключение может быть сгенерировано только по причине невозможно записать в ЛОГ, а не по причине отсутствия доступа к файлу. Да и собственно твоя переменная file объявленная в заголовке цикла, вообще не используется в теле нигде.
Отдельно скажу, что пытаться проверять наличие доступа к файлам с помощью исключений это полный треш. Более того, если доступ на запись будет, и ты чтото в файл запишешь, как интересно ты будешь отменять это действие?
И да, мы надеемся что ты выпустил пар, т.к. большинство не будет продолжать разговор с тобой в таком тоне.
как раз вникнуть в архитектуру стоит, если выясняется что на SQL нужно городить огород. Базе потом ваши запросы выполнять еще)). Если вам важен порядок, попробовали бы хранить id предудыщего кейса, после которого стоит текущий. Т.е. если кейс с id=16 стоит после кейса с id=19 то и хранили бы prev_id=19 у 16-го кейса. Так вы сохраните именно порядок. Нормализовать вам сейчас нужно изза того, что вы храните данные не о взаимном порядке, а фактические индексы ваших кейсов, КАЖДЫЙ из которых зависит от ДРУГИХ и при изменении одного (удаление/перестановка одного из кейсов) вам нужно менять все, а не одну/две записи (иными словами, в каждом индексе у вас избыточность). Это и приводит к необходимости нормализации этих индексов.
Если не хотите ничего менять, по SQL-запросу пока не могу подсказать, т.к. запрос в этом случае будет императивный: у вас содержимое ordered в одной записи зависит от того, что находится в другой. Пахнет циклом, так что я советую вам не морочиться, а сделать хранимую процедуру, запилить в ней обычный цикл, и вызывать хранимку из php-кода при необходимости.
Назначение поля ordered честно говоря так и осталось загадкой, такое ощущение что оно впилено вообще непонятно для каких целей. Если вам нужно "восстанавливать" нумерацию, то может нафиг не надо ее вообще где-то ХРАНИТЬ? человек вам говорит эту нумерацию генерировать тем кодом, который читает эти данные из базы. Если кому-то в интерфейсе нужен список и номера строк в нем, и эти номера НЕ привязаны к самим строкам (т.е. не являются данными с точки зрения предметной области), как в вашем случае, то никто не хранит эту нумерацию в базе, она генерируется по ходу дела. вы просто выбираете запросом c ORDER BY нужные вам строки, а потом, когда показываете их, уже добавляете номера, и все. Грубо говоря, далеко не все что у вас показывается в HTML-табличке, ну или в DataGrid каком-нибудь, должно находиться в SQL-таблице.
А по-моему весьма полезный ответ. В целом, человек спрашивает "как мне сформировать рабочий процесс верстки сайта?". Ему ответили на собственном примере - какие инстурменты использовать и в каком порядке, как структурировать исходники, как работать со стилями. Если это все попытаться повторить - немало вопросов отпадут сами собой. И да, где тут про деплой мне тоже непонятно - после выполнения указанных шагов должна получиться develop-структура сайта.
В первом случае просто укажите пустой массив параметров. Сигнатура Invoke требует указания массива параметров, даже если количество параметров - ноль. Аналогично на втором скрине - у метода GetMethod есть несколько сигнатур, но ни одна не принимает параметры (string, System.Type), ближайшая подходящая для вашего случая - (string, System.Type[]). Поэтому также оберните typeof(int) в массив: new System.Type[] { typeof(int) }.
Если укажете, что за ошибки во втором примере и Invoke, тогда вместе и подумаем, что может быть не так. Касательно первого варианта - возможно еще проще было вообще не пользоваться рефлексией явно, а просто проверить райнтам-тип вашего obj. например, так if (obj is IEnumerable) { IEnumerable array = obj as IEnumerable; ... }. Таким образом ваш код будет максимально общим - если для действий над элементами вам нужно, чтобы они были IEnumerable, то ИМЕННО ЭТО и следует проверять. В таком случае ваш код сможет обработать еще и List. И да, если возможно, старайтесь использовать дженерики, например IEnumerable вместо IEnumerable.
Если через временный файл - не вариант, то советую посмотреть какие еще есть библиотеки/контролы для рендеринга pdf в WinForms. Можно попробовать MigraDoc (www.pdfsharp.net/wiki/DocumentViewer-sample.ashx), только проверьте лицензию. В любом случае, вам нужна либа которая отрисует PDF из Stream-а или byte[]. Тогда тот бинарник, что вы вытащили из базы, можно будет скормить ей. Боюсь, что с webbrowser-ом и Адобовским контролом это будет непросто. Альтернативный вариант - запустить из этого же приложения крошечный веб-сервер, который будет отдавать в браузер-контрол pdf-ку, но это, как мне кажется, крайние меры.
Согласен, XP уже достаточно древняя система, чтобы заставить сидящих на ней пользователей что-то да поставить/обновить. .NET4 под XP работает вполне неплохо, в том числе WPF.
вектор может быть из чего угодно. может быть vector, может и vector, а может и vector. Есть конечно определенные требования к типу элемента, о них можно почитать по ссылкам приведенным выше.
Проверьте, что соглашение о вызове - именно cdecl, потому что если это не так, вызов функции по неверному соглашению может привести к порче состояния вызывающего (регистры, стек и т.д.), после этого можно всякое ожидать.
Очередь сообщений абстрагирует ваше межпоточное взаимодействие - отправитель (ваш менеджер порта) будет помещать в нее логические сообщения, а потребитель (в данном случае - GUI поток), будет извлекать их оттуда время от времени (когда ему удобно) и обрабатывать (менять состояние контролов). Своя очередь бы вам понадобилась наверняка, если б у вам был не GUI-поток, а, например, серверный, обработывающий запросы из сети. А так как вам операционка фактически уже дает очередь (которая по определению есть у каждого окна и куда летят события мыши/клавиатуры/перерисовки), то вполне вероятно Invoke-a, который через нее работает, вам будет достаточно. Собственно еще один плюс своей очереди сообщений - то что она отделена от виндовой - если у вас Invoke-и от менеджера портов будут приходить слишком часто, виндовая очередь будет захламляться ими, вытесняя WM_PAINT, и интерфейс будет туго перерисовываться. В случае отдельной очереди вы можете просматривать ее тогда, когда сами считаете нужным (например, не чаще чем раз в полсекунды).
про пул подключений: https://msdn.microsoft.com/en-us/library/bb399543%... . А вообще - любую книгу про современный asp.net mvc (www.amazon.com/gp/product/1430242361), туториалы на www.asp.net/mvc , в том числе по работе с данными через entity framework, поищите также про паттерн Repository. Вот еще неплохое описание жизненного цикла asp.net mvc приложения: i3.asp.net/media/4773381/lifecycle-of-an-aspnet-mv... - как раз написано когда создается контроллер, когда вызываются действия и т.д.
весьма неудачная затея. Вы наполовину убиваете преимущества многопоточной обработки запросов тем, что обращаетесь к базе через одно подключение. Работать с ним вам необходимо будет внутри критической секции, чтобы его не схватили несколько потоков сразу, и по большей части запросы будут ждать друг друга. Также почитайте про database connection pooling в дотнете - там будет написано, что создание и уничтожение объекта подключения вовсе не значит, что создается/уничтожается физическое подключение к базе по сети. Общепринятой практикой считается открытие и закрытие подключения в каждом обработчике.
Дело в том что static-поля это далеко не лучший способ хранить состояние в ASP.NET приложении и если это не лабораторный тест, то лучше воспользоваться application state.
Доступ к static-полям нужно синхронизировать, т.к. разные инстансы контроллера могут быть созданы в разных потоках. Блокировки для статических полей не нужны только если вы инициализируете их однократно, а в контроллерах используете только на чтение. А, кстати, зачем вам static-поля?
> Я думал что new только для создания объектов.
new может создавать как единичные экземпляры, так и массивы примитивных или пользовательских типов. Он совмещает выделение в куче нужного объема памяти и вызов конструктора, если вы создаете экзмепляр пользовательского типа (т.е. класса).
Вообще, векторный new это конечно вещь более чем работающая и выполняющая свои задачи, но все же это наследие из Си. И используют ее как правило в критичных к производительности местах, нередко оборачивают в более крупный класс, чтобы быть уверенным в безопасности работы с массивом на куче. Поэтому, почитайте и сравните классы из стандартной библиотеки: en.cppreference.com/w/cpp/container/array , en.cppreference.com/w/cpp/container/vector . Для вашей задачи вектор - самое оно, т.к. вы заранее не знаете сколько вытащите записей из БД.
Отдельно скажу, что пытаться проверять наличие доступа к файлам с помощью исключений это полный треш. Более того, если доступ на запись будет, и ты чтото в файл запишешь, как интересно ты будешь отменять это действие?
И да, мы надеемся что ты выпустил пар, т.к. большинство не будет продолжать разговор с тобой в таком тоне.