Что так же плохо об использовании подписей кнопки как переменные в VB6?
Если я понимаю ваши желаемые результаты, вы, вероятно, можете просто использовать Values , SelectMany и Where .
var result = teamkillCounter.SelectMany(x => x.Value.Where(y => y.killerName.Contains("bobo")));
Получает коллекцию, содержащую значения в словаре.
blockquote>Проецирует каждый элемент последовательности в
BLOCKQUOTE>IEnumerableи объединяет результирующие последовательности в одну последовательность.
7 ответов
Я думаю, что лучше отделить текст подписи от состояния обработки. Также goto's мешает читать. Вот моя пересмотренная версия...
Private Const Caption_Start As String = "Click to Start Doing the Thing"
Private Const Caption_Stop As String = "Click to Stop Doing the Thing"
Private Enum eStates
State_Initialized
State_Running
State_Canceled
State_Completed
End Enum
Private Current_State As eStates
Private Sub Form_Initialize()
DoTheThing.Caption = Caption_Start
Current_State = State_Initialized
End Sub
Private Sub DoTheThing_Click()
If Current_State = State_Running Then
'currently running - so set state to canceled, reset caption'
'and disable button until loop can respond to the cancel'
Current_State = State_Canceled
DoTheThing.Caption = Caption_Start
DoTheThing.Enabled = False
Else
'not running - so set state and caption'
Current_State = State_Running
DoTheThing.Caption = Caption_Stop
'do the work'
For i = 0 To ReallyBigNumber
Call DoSomethingSomewhatTimeConsuming
'at intervals check the state for cancel'
If Current_State = State_Canceled Then
're-enable button and bail out of the loop'
DoTheThing.Enabled = True
Exit For
End If
DoEvents
Next
'did we make it to the end without being canceled?'
If Current_State <> State_Canceled Then
Current_State = State_Completed
DoTheThing.Caption = Caption_Start
End If
End If
End Sub
Единственная самая большая проблема с этой техникой состоит в том, что она использует строку в качестве булевской переменной. По определению логическая переменная может иметь только два состояния, в то время как строка может иметь любое количество состояний.
Теперь, Вы смягчили опасность, свойственную от этого несколько путем доверия массиву предопределенных строк для определения позволенный значения для текста кнопки. Это оставляет горстку меньших проблем:
- Логика является меньше явной относительно текущих и доступных состояний (существует на самом деле четыре возможных состояния для формы: не - запустился, запущенный, завершенный, запускать-но-отменять) - обслуживание потребует, чтобы тщательное наблюдение за потенциальными взаимодействиями между текстом кнопки и состояниями логической переменной определило то, что текущее состояние / должен быть. Единственное перечисление сделало бы эти состояния явными, делая код легче читать и понять, таким образом, упростив обслуживание.
- Вы полагаетесь на поведение свойства элемента управления (текст кнопки), чтобы остаться согласовывающимися с тем из выставленного типа значения свойства (строка). Это - вид предположения, которое делает мигрирующий старый код VB6 на более новые языки / платформы абсолютный ад.
- Сравнение строк очень, намного медленнее, чем простой тест логической переменной. В этом экземпляре это не будет иметь значения. В целом столь же легко избежать его.
- Вы используете DoEvents для моделирования многопоточности (не непосредственно относящийся к вопросу..., но, тьфу).
Самая большая проблема, через которую я приехал, продолжая работать (очень старый) код как это [подписи кнопки как переменные], - то, что глобализация является кошмаром.... Я должен был переместить старое vb6 приложение для использования английского и немецкого языка... потребовались недели, если не месяцы.
Вы используете goto's, также..... немного рефакторинга должно было, возможно, сделать код читаемым??
** Редактирование в ответ на комментарии я только использовал бы goto в vb6 наверху каждого proc; на ошибке goto myErrorHandler.
затем в самой нижней части proc у меня был бы один лайнер, который передаст, допускают ошибку к глобальному обработчику, для входа ошибки.
Игнорирование общей архитектуры / связывающиеся проблемы, потому что Вы знаете о тех проблемах, одной проблеме с Вашим подходом, состоит в том, потому что средства управления VB6 делают волшебный материал при установке свойств. Можно думать, что Вы просто устанавливаете свойство, но во многих случаях Вы заставляете события стрелять также. Устанавливание значения флажка к истинным огням событие щелчка. Установка tabindex на управлении вкладкой вызывает событие щелчка. Существует много случаев.
Если я помню правильно, что я также думаю, что существуют сценарии, где, если Вы устанавливаете свойство и затем сразу читаете его, Вы не будете видеть обновление. Я полагаю, что экранное обновление должно произойти перед наблюдением нового значения.
Я видел, что слишком много ужасного VB6 кодирует, который использует свойства элементов управления в качестве устройства хранения данных. Если Вы когда-либо найдете этот вид кода, то Вы распознаете его, потому что он рассеивается с избыточными вызовами для Обновления методов, DoEvents, и Вы будете часто видеть, что UI подвешивается. Это часто вызывается бесконечными циклами, где свойство установлено, событие запущено, и затем другое свойство установлено, и в конечном счете кто-то пишет строку кода, которая обновляет первое свойство снова.
Если те проблемы не пугают, Вы достаточно затем думаете об этом. Некоторые из нас просто не настолько умны. Я кодировал в VB6 больше 10 лет и лично записал, вероятно, вокруг 750K LOC, и я продолжаю уставиться на Ваш пример выше, и я нахожу очень трудным понять что он продолжение. Предположите, что все люди, которые должны будут прочитать Ваш код в будущем, будут действительно немыми и сделают нас счастливыми путем написания действительно просто выглядящего кода.
Это связывает Ваш базовый алгоритм с определенным поведением в Вашем UI. Теперь, если Вы хотите изменить любого из них, необходимо внести изменения в обоих. Поскольку Ваше приложение увеличивается в размере, если Вы не сохраните свои изменения локальными путем инкапсуляции логики, то обслуживание станет кошмаром.
Кроме удаления GOTos, поскольку ди-джей сделал в своем ответе, нет ничего действительно неправильного относительно Вашего подхода. Подпись кнопки может иметь только два состояния, и Вы используете те два состояния для определения потока в коде.
У меня есть однако две причины, почему я сделал бы это по-другому:
- Ваш метод создает проблемы, когда Вы хотите перевести свою программу на другой язык (по моему опыту, необходимо всегда планировать тот), потому что подписи изменились бы на другом языке
- Это идет вразрез с принципом разделения пользовательского интерфейса от процесса выполнения программы. Это не может быть важной вещью для Вас, но когда программа становится больше и более сложной, имение четкого разделения UI от логики делает вещи намного легче.
Для подведения его для случая под рукой решение, конечно, работает, и нет никакой причины, почему это не было должно. Но с другой стороны опыт учил нас, что с более сложными программами, этот путь может вызвать проблемы, которых можно легко избежать при помощи немного отличающегося подхода.
Кроме того, я думаю, что безопасно предположить, что все, кто подверг критике Ваш пример, сделали так, потому что они сделали simnilar выбор в какой-то момент и позже поняли, что это была ошибка.
Я знаю, что сделал.
Если кто-либо по какой-либо причине когда-нибудь должен работать над Вашим кодом, они не найдут методы и конвенции, которыми они знакомы и довольны, таким образом, границы функциональности не будут существовать. Другими словами, Вы идете в неправильном направлении на следе Связи/Сцепления. Функционально интегрирующееся управление состоянием с UI является классическим ребенком плаката для этой проблемы.
Вы понимаете ООП вообще? (Не критика, а законный вопрос. Если бы Вы сделали, то это было бы намного более ясно Вам. Даже если это - только ООП VB6.)