|
Need urgent help, Please reply ASAP.
We are working on a VB 6.0 to VB.Net migration project which is using lots of different third party controls for e.g. “Crescent enhanced edit controls” which is provided by the vendor Crescent Quickpack.
In a VB 6.0 code file we have a third party control as “CSTextLibCtl.sitxEdit” which exposes following properties.
Begin CSTextLibCtl.sitxEdit csParticulars
Height = 375
Left = 2280
TabIndex = 4
Top = 240
Width = 1455
_Version = 262145
_ExtentX = 2566
_ExtentY = 661
_StockProps = 125
ForeColor = -2147483640
BackColor = -2147483643
BeginProperty Font {0BE35203-8F91-11CE-9DE3-00AA004BB851}
Name = "MS Sans Serif"
Size = 8.24
Charset = 0
Weight = 400
Underline = 0 'False
Italic = 0 'False
Strikethrough = 0 'False
EndProperty
Modified = -1 'True
HideSelection = -1 'True
RawData = ""
Text = ""
StartText.x = 2
StartText.y = 6
FirstVisPos = 0
HiAnchor = 0
HiNew = 0
CaretHeight = 13
CurNumDataChars = 0
MaxDataChars = 0
FirstDataPos = 0
CurPos = 0
MaxLen = 0
DataReadOnly = 0 'False
Mask = ""
CharacterTable = ""
End
However when we migrate the form containing this control to VB.Net using migration tool “ArtinSoft” it migrates the code as shown below.
Public WithEvents csParticulars As AxCSTextLib.AxsitxEdit
.
.
Me.csParticulars = New AxCSTextLib.AxsitxEdit
.
.
.
CType(Me.csParticulars,
.
.
System.ComponentModel.ISupportInitialize).BeginInit()
'
'csParticulars
'
Me.csParticulars.Location = New System.Drawing.Point(152, 16)
Me.csParticulars.Name = "csParticulars"
Me.csParticulars.OcxState = CType(resources.GetObject("csParticulars.OcxState"), System.Windows.Forms.AxHost.State)
Me.csParticulars.Size = New System.Drawing.Size(97, 25)
Me.csParticulars.TabIndex = 4
Me.Controls.Add(Me.csParticulars)
.
.
.
CType(Me.csParticulars, System.ComponentModel.ISupportInitialize).EndInit()
(the above code is present in designer form)
As can be seen from the above code snippet out of approximately 30 properties only 4 properties are mapped in VB.Net and rest all are embedded in “OcxState” object.
We wanted to have a one is to one mapping of Third party control properties to VB.Net Custom control (which we have developed) properties. However since no properties are visible in the migrated code we are not able to do the mapping. We even tried to decode the “OcxState” object that is present in the “Resx” file in the Base64 format. However that also didn’t work. Now we are stuck up at this point where untill we have this mapping we wont be able to replace the Third party controls with the VB.Net Custom controls.
We would appriciate any inputs on how to capture third party control properties and their values in the migrated code so that we can establish the required mapping.
|
|
|
|
|
akanchu wrote: Need urgent help, Please reply ASAP.
No. Demanding urgent help around here is rather rude and impolite 
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
See if I have this correct.
1. You have a 3rd party VB control
2. You have a self-written VB.Net custom control
3. You are using a 3rd party tool to convert your VB6 to VB.NEt
akanchu wrote: However since no properties are visible in the migrated code we are not able to do the mapping.
Why not? You have the properties (you listed them) and you claim you wrote the custom control. Or is it that you are suprised the convertor doesn't map the VB6 control to your custom control?
Well, I would have been more suprised if it did.
And you expect someone who doesn't have your source code to tell you what to do URGENTLY.
Well, its your code....
Bob
Ashfield Consultants Ltd
|
|
|
|
|
There is nothing that's going to automatically figure out that your custom control is supposed to replace another control and automatically remap the properties. I would have been blown out of the water had this really worked! You'd just going to have to rewrite the code by hand. A conversion tools is not ment to convert code for you guaranteed 100% accurate, even without the goofy replacement of an existing control with another. Coverting code is not a "one-click on a tool" process. Covnerting code, evenusing a tool to do most of it is still a full-blown developement project.
|
|
|
|
|
I'm writing an asp.net web application. I want to filter automated requests that are made from some software.
How can i find out automated requests. I mean how can i differentiate automated request and user made request.
fine
|
|
|
|
|
Perhaps you would get more answers on ASP.NET [^]-forum
The need to optimize rises from a bad design
|
|
|
|
|
Hi, i had developed a application for automatic navigation in URL and save information to disk. I'm using webbrowser control.
All is correct, but, i have a problem!!!
When the application is navigate, 'alert' window is open and the application stop.
How i close 'alert' window in code ???
I supossed the solution is complicate but I'm sure this is possible.
Thanks
|
|
|
|
|
Hello gurus 
the funny little problem now comes from a timer component. The main code starts the timer (interval 1) and - right afterwards - a BackgroundWorker component. I intend to count the seconds which the BW needs for his task.
Realizing that the time-label in my form wasn't updated (through 'lblTimer.refresh' in the Timer_Tick event), I stepped through the code and had to see that the Timer_Tick event just isn't called at all   and even a stopmark I placed within the event was ignored. Searching for possible reasons didn't bring me much further yet.
My question: Is there anything (apart from stopping the timer) that makes VB ignore the Timer_Tick event completely? Or are there any imaginable reasons for that behavior?
Thank you for inspiration,
Michael
|
|
|
|
|
Most likely the timer isn't enabled or Timer_Tick event isn't wired.
Also reconsider if you really need interval of 1 millisecond.
The need to optimize rises from a bad design
|
|
|
|
|
Hi Mika,
as the timer is surely enabled I have to ask you what 'it isn't wired' would mean? I thought as soon as the timer is started the tick-event would start until the timer is stopped?
You're surely right regarding the interval which I had set to 100 before. When I'm back to a reliable tick-event I guess I can switch that back since it's only needed for the form's update. I hope with your help I'll have a timer-tick again soon ...
I found a weird effect, too: running the app from debug-mode, the tick-event seems to run sometimes and therefore update my timer-label - I just can't tell the exact conditions. It feels a bit like the Backgroundworker eventually blocks the timer...(is there no 'DoEvents' or similar command to put there anymore?) like under 'race conditions'.
I thought I'd probably post a part of the code:
Private Sub Main()
UpdateDriveInformation()
ProgressIndicator.Style = ProgressBarStyle.Marquee
startTime = Now
Timer.Enabled = True
If PROC_MAKELIST Then
ThreadID.Text = TXT_MAKELIST
BackgroundWorker2.RunWorkerAsync()
Else
ThreadID.Text = TXT_DELREPORTS
GroupBox1.Text = TXT_MAKELIST
BackgroundWorker3.RunWorkerAsync()
End If
End Sub
Private Sub Timer_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer.Tick
Dim mDbl As Double = Now.ToOADate - startTime.ToOADate
Dim mDat As DateTime = DateTime.FromOADate(mDbl)
Try
Dim mDat2 As Date = Date.FromOADate(mDbl)
lblTimer.Text = mDat2.ToString("mm:ss")
Catch ex As Exception
lblTimer.Text = "Timer Error!"
Err.Clear()
Finally
lblTimer.Refresh()
End Try
End SubMaybe you see something wrong here?
Thanks for now
modified on Sunday, September 28, 2008 11:35 AM
|
|
|
|
|
By wiring I mean that you have an eventhandler attached to the objects event. From your code I suppose that Timer refers to the object drawn to the window.
At a glance I don't see anything special in your code but all necessary operations are not included. I take it that the rest is defined in Designer.vb (for example interval and so on).
One possible problem you may encounter is that Tick isn't necessarily raised while debugging. This could be one reason why it sometimes is run and sometimes not.
The need to optimize rises from a bad design
|
|
|
|
|
Thanks for checking.
You're right, I did the form in the designer and it refers to lblTimer - which is nothing than kind of a stopwatch - drawn to the window. After building an exe and starting it several times, I have to say that it's exactly the same effect: Sometimes it starts counting (one or two seconds was the maximum), sometimes the label just stays at 0.
Would it be possible that the Backgroundworker blocks the timer... something like 'race conditions'?
modified on Sunday, September 28, 2008 1:00 PM
|
|
|
|
|
For a race condition you should use a common resource in both threads. And even if that's true, it should appear when you use the resource, not on timer tick.
However, it's possible that you are blocking the whole UI thread (I take it that the timer is in main UI thread) and in that case the tick won't occur. If that's true your UI should also be non-responding.
There's also the possibility that the timer's enabled property goes to false. Try using debugger and add a conditional breakpoint to timers enabled property and define the debugger to stop every time the value changes. This helps you to eliminate that possibility.
The need to optimize rises from a bad design
|
|
|
|
|
Hi Mika,
thanks for still taking care.
Mika Wendelius wrote: The need to optimize rises from a bad design
I have to admit that being a newbie I seem to fall into almost every bad design trap I can find 
What I did meanwhile is that I eliminated the timer as well as the Backgroundworker. Instead of that, the looping function (which used to be in the background worker) calculates the time elapsed within every loop and updates my lblTimer label. This way might not be elegant (and I still didn't learn how to use the Timer right) but it works  for my small purpose and I see how much time the function needed.
Mika Wendelius wrote: However, it's possible that you are blocking the whole UI thread (I take it that the timer is in main UI thread) and in that case the tick won't occur. If that's true your UI should also be non-responding.
I had started the timer in the main UI thread of a form, in which (I guess) also the Timer_Tick event runs (I placed the component in the form). The update of the lblTimer label was supposed to come from the Timer_Tick event (after starting / before ending the timer) every second and independently from the looping stuff done in the backgroundworker (that was the idea). Other controls (a progressbar and another label), which are updated in the backgroundworkers ProcessChanged event, do update with every loop!
Do you think it's possible that the BW takes so much of the processor time that it doesn't leave any for the main thread? Somehow that doesn't make sense for a backgroundworker, does it?
|
|
|
|
|
Oops,
That optimizing thing is only my signature. I think I should remove so that people won't take it badly. It certainly wasn't targeted to you! Sorry for that.
If you're reading or updating lblTimer in background worker, you may block the timer (or actually the UI) and it can cause you several other problems since UI elements must be updated only in UI thread. Also if the backroundworker continuously uses the lblTimer, it may cause a collision with the timer in event handling.
Just a question: Why don't you update the elapsed time in Timer_Tick instead of using backgroundworker? It could simplify the code a lot. For what you described I don't see the benefit of using backroundworker. Another possibility is to use two separate timers in which case they would still be under the same thread, but I'm not sure that iven that is needed
Mika
The need to optimize rises from a bad design
|
|
|
|
|
Don't mind your signature  it's a good reminder to learn, anyway, and I didn't take it personally.
Something you misunderstood: I didn't update lblTimer (a label on the main form) in background worker, but in the Timer_Tick event. Other controls (progress bar etc.) were updated in background worker (process_changed).
The use of a background worker arose from the idea NOT to block the UI with long lasting (looping) function (purpose: listing of large directories in a given path). So my basic concept for that seemingly simple thing was:
1. Start the timer from the forms main routine
2. Start a background worker (also from the forms main routine)
3. Let the timer count the seconds while user sees a marquee-style progress indicator as long as the background worker is running
4. Stop timer when background worker is finished
Actually I tried out the whole BW / Timer stuff to learn something about better design but it seems I'm trapped somewhere 
|
|
|
|
|
Ok,
As far as I can tell, the basic idea seems good. And if the backgroundworker isn't accessing any UI elements directly, you should be safe. However, if the timer and the BW share some variables, arrays etc, you should lock them before accessing (not sure what is the keyword in VB but in C# it's lock).
Perhaps if you strip the code to the minimum and then try bringing it back piece by piece, you'll find out what went wrong.
The need to optimize rises from a bad design
|
|
|
|
|
If at least my basic idea was ok, then I might give the timers and background workers another chance
Still it might have been the problem that my Timer_Tick event was supposed to change ONE element (lblTimer) on the form (but didn't) while background worker changed OTHER elements on the same form (and did!). No similar variables, but still accessing the same form.
Thank you very much for your help, Mika!!!
Regards
Michael
|
|
|
|
|
You're welcome 
I believe that this can be useful to you if you haven't read it already:
Control.InvokeRequired Property [^]
Mika
The need to optimize rises from a bad design
|
|
|
|
|
I would just blame all your timer problems on the financial market - kidding!
Any suggestions, ideas, or 'constructive criticism' are always welcome.
|
|
|
|
|
The financial market already blamed the timer problems 
|
|
|
|
|
hi all ,
i want to print the values as crystel repots
Regards
Vidhish
|
|
|
|
|
I want a Tesla. clickety[^]
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hello everybody,
before I go mad with all these error messages, I want to ask someone who knows... How can I simply shorten a path with regular expressions, just the way Windows does it in many dialogs?
Input:
C:\program files\Visual basic examples\GMTest\Pictures\pic00001.jpg
Output:
c:\program files\....\pic00001.jpg
In words: The output string contains the start input sting until the 2nd "\", then followed by "...", and the end of the new string starts with the last "\" of the input string.
re = New Regex("^(?'start'.*\\.*)\\.*\\(?'end'\w*)$")
tmpText = re.Match(Text).Result("${start}...\${end}")does quite a good part of the job but still unsatisfying.
I've been trying to figure out regular expressions for hours already, but now I'm stuck and can't get a reasonable result. Could anybody help, please?
Thank you,
Michael
|
|
|
|
|
Finally - after ages - I can answer my own question  as an inspiration for anyone else with a similar problem:
re = New Regex("^(?<start>\w:\\[\w\s]+\\).*\\(?<end>.*)$")
tmpText = re.Match(Text).Result("${start}...\${end}")</end></start>returns exactly the desired output string! Very useful e.g. for indicators when looping through a directory structure.
Regards
Michael
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
