|
Fixed, in this case "UL" was the correct suffix to "cast" the number to UINT32
|
|
|
|
|
that would be "UI" not "UL", in .NET "long" variables take 64 bit, you don't need that, do you?
|
|
|
|
|
|
the prototype should indicate either an array or a pointer, so try this:
<DllImport("kernel32", EntryPoint:="WriteFile", SetLastError:=True)> _
Private Shared Function WriteFile(ByVal handle As IntPtr, ByRef bytes As Byte(), ByVal numBytesToWrite As Integer, ByRef numBytesWritten As Integer, ByRef overlapped As OVERLAPPED) As Integer
End Function
I made bytes an array of bytes, not a single byte.
I expect that to work for you, I haven't done it in VB.NET yet, I normally do C# (and P/Invoke from C# to C).
|
|
|
|
|
That was my appraisal as well, I did "fix" the pinvoke method by adding the () making bytes an array BUT as I made that change I thought to myself "that probably wont work" and so I decided to ask for help.
I havent yet figured out the ins and outs of pinvoking so I am still overly cautious to change things. Love the wiki, hate the "trial and error" part of pinvoking 
|
|
|
|
|
There is http://www.pinvoke.net[^], which is interesting, not always accurate, sometimes not complete. It does not offer a VB prototype for WriteFile!
I am (or should still be) working on this article[^]; what it says about passing arrays is correct, but there is a simpler way I haven't mentioned nor fully tested yet, and that is your way.
|
|
|
|
|
Ah I have read it some time ago when I first encuntered pinvoking problems, at the time it seemed a large wall of text so I skipped over most of it, only looking at the bits that interested me, now that I have more knowledge I will read it once again.
Thats the problem with really detailed articles, one should really read them more than once, and at different time, as one progresses in knowledge. Its like watching Star Wars as a kid and as an adult, different things. Things stops revolving around light sabres and Leia become interesting
|
|
|
|
|
you are mixing signed and unsigned integers. It isn't very important which you choose, however being consistent is what matters. So either make BR an unsigned integer (use the U suffix again!), or modify the structure to a signed baudrate. The P/Invoke stuff will not mind you doing so.
|
|
|
|
|
|
Hrizip wrote: Dim key As New RegKey(&H80000002)
I don't know what class RegKey is, nor what constructor(s) it has. If it needs an unsigned integer parameter, once again apply a U suffix or switch to a signed integer definition.
|
|
|
|
|
|
Hrizip wrote: wrapper = New CallbackWrapper(Me) '{.DoOnCTS = True, .BoolData = Me.m_old_cts}
So try a multi-line approach, along the lines wrapper.DoOnCTS = True
FYI: You may or may not prefer to apply a With construct.
|
|
|
|
|
Some overall comments:
1.
I have my doubt you will ever get this to work; it looks like a lot of code is present, none of which is yours, no source and no documentation available. Normally one starts from scratch, creates a little piece of code, gets it to work, then expand it a bit, etc. That way most if not all code is familiar and in working order all of the time. You will have a lot of code, some mistakes, and not much that works I expect.
2.
You can tell Reflector to show a method in a language of choice. If VB.NET is not your prime language, and maybe C# is, it may help to look at the C# code it suggests.
3.
I was told there are add-ins for Reflector that would turn an entire DLL into source code right away.
4.
There are programs, and web services, that translate code from one .NET language to another. I use them occasionally when trying to answer questions here on this forum.
5.
Make Google your friend. All of MSDN and heaps of useful articles will be at your disposal, simply by entering a few keywords.
|
|
|
|
|
I seem to be learning best the hard way, every time I try learning something the easy way I end up not knowing anything. This is why I love looking at other peoples code and learning their syntax. I have done a lot of work on my own serialport classes under VB.NET so most of this code is known to me. The unknown parts being delegating and event handling.
I havent found a good tutorial on using delegates under VB.net nor on event handling, but I have both present here in this code sample, now if I could (given enough time) reverse engineer this, I would end up understanding both on a relatively known problem (serial port communication).
VB.net is my language of choice, but I had done some minor work in C#, I have already compared C# and VB.net reflector outputs and this did help me solve SOME of the problems, just not all.
I would be interested in reflector addon that turns an entire dll into source code, I have been searching under addons for it, but I havent been able to find it, is it third party (not listed on reflectors home page)?
Yeah there some sort of a plugin for VS that handles PINVOKING, I also use it a lot.
Turns out that using google shake and bake solutions makes me patchwork code together without knowing WHY it works, unfortunately due to time constraints on my projects, I do the majority of things this way. AFAIK most programmers do. It makes me feel unsecure about my knowledge and the behaviour of the code that isnt all mine.
I love learning how the stuff actually works.
|
|
|
|
|
IMO the quickest way to learn a new technology is by reading a book about it. A tutorial is meant to take you from zero to first understanding; you will not be getting why things are done a particular way, and not another way, just by looking at existing code.
I can't help you with articles on delegates and events if you insist on them using VB examples.
|
|
|
|
|
Fixed a few things;
1) Delegate is a system.delegate method so there was a problem in namespaces, had to explicitly state what a "DELEGATE" is (a system.delegate in this case)
2) Unresolved at this time, mostly because I am clueless when it comes to delegates
This is the C# variant of one of the events/delegates:
public delegate void OnForceClose(int ErrorCode);
public event OnForceClose OnForceClose;
When expanded it reveals the following:
[MethodImpl(MethodImplOptions.Synchronized)]
public void add_OnForceClose(OnForceClose value)
{
this.OnForceClose = (OnForceClose) Delegate.Combine(this.OnForceClose, value);
}
[MethodImpl(MethodImplOptions.Synchronized)]
public void remove_OnForceClose(OnForceClose value)
{
this.OnForceClose = (OnForceClose) Delegate.Remove(this.OnForceClose, value);
}
VB.net variant looks like this:
Public Custom Event OnForceClose As OnForceClose
MethodImpl(MethodImplOptions.Synchronized) _
Public Sub add_OnForceClose(ByVal value As OnForceClose)
Me.OnForceClose = DirectCast(Delegate.Combine(Me.OnForceClose, value), OnForceClose)
End Sub
MethodImpl(MethodImplOptions.Synchronized) _
Public Sub remove_OnForceClose(ByVal value As OnForceClose)
Me.OnForceClose = DirectCast(Delegate.Remove(Me.OnForceClose, value), OnForceClose)
End Sub
I have no idea what this does, I can make an educated guess and say that this delegate is "announced" by using an older routine that does not use "add handler", "remove handler" and "raiseevent" instead it plugs into an older system.delegate method and therefore uses a different way of adding and removing a handler (see c# example).
The VB example seems to show how to splice two delegates (or events) into one by the means of system.delegate.combine method, I have no idea why this is used in this example and what it should accomplish.
I would need to find out what the difference is between the above mentioned examples and the addhandler/removehandler/raiseevent (which I am partly familiar with) and then try to recreate the whole thing.
Any help/insight would be most welcome.
|
|
|
|
|
Hi again,
in normal situations, you don't need to go into the internals of events, i.e. I don't expect you would need Delegate.Combine at all. In normal circumstances, all the code you would need is what can be found in the MSDN example here[^]. There are three parts:
1. event declaration, with event keyword
2. event set-up, based on AddHandler
3. event processing, which looks like a regular method you have to provide.
|
|
|
|
|
I am looking into it right now, hopefully I will be able to rewrite the functionality of this part of code using normal VB.net syntax as shown on MSDN.
That is the only remaining error by the way, I have fixed all the other errors except for this one concerning events and delegates.
|
|
|
|
|
Dim numRef As Byte*
Fixed numRef = buffer
I have this thing that puzzles me. 
I suppose that fixed means that garbage collector isnt allowed anywhere near the memory location to prevent accidental removal.
That I can do in VB.net. 
On the other hand I have no idea what Byte* is, seems to me its a pointer, what I do know from debugging is that it seems to retain only the first element in buffer (which is an array of 1023 I think, irrelevant at this point).
Does the pointer point only to the first element? 
So if you store 1023 bytes in byte* it retains only the first byte?
Please help 
Added more info at 12:00
The next line of code is the following;
flag2 = Win32.ReadFile(Me.m_handle, numRef, 50, (numBytesRead), AddressOf overlapped)
numref in this case is taken from the line before and hence flag2 returns boolean true. Interesting thing is, in my patchwork code I use the following
Dim flag2 As Boolean = False
Dim numRef As Byte() = Nothing
numBytesRead = Nothing
numRef = buffer
flag2 = False
flag2 = Win32Serijski.ReadFile(Me.m_handle, numRef, 50, numBytesRead, overl)
And in contrast to the original code, my flag2 ALWAYS returns TRUE, while in the original code it returns true only if theres NEW data in the buffer.
|
|
|
|
|
Hi everybody,
I'm struggling with the creation of an Office-AddIn in Visual Basic Express 2008 (for code and details please see this message). The code is similar to several examples I found on the net and it used to fully work before, but now it makes trouble. The project compiles well, all components can be registered (also the tlb) and the registry entries seem to be all ok. I can even call methods of the AddIn from Excel VBA, but a toolbar button doesn't get installed. It actually seems as if all the connection-events just don't fire.
What I could use now is some advice on how to debug the dll in runtime, i.e. examine the connection process in order to find out exactly where the assumed error(s) occur. Does someone of you know a way (VB Express) or a (free) tool which might help in that? I'm really trapped in the dark and running in circles right now... 
Thank you for advice,
Mick
|
|
|
|
|
Hi Michael,
I don't know what the official answer would be; there may well be a fancy tool or command to solve your problem right away.
However this is what I would do, all very basic, nothing fancy at all; its main purpose is to increase observability and tracability:
- create a log method that somehow logs a one-line message
- make sure try-catch blocks are present where useful
- add log statements to the code, in order to trace progress and report all exceptions
- check that there are no empty catch blocks nor finally blocks
Assuming your allowed to create and write files, a log method could be (not tested in VB!):
Public Shared Sub Log(msg as String)
File.AppendText("<path to a writable location on disk, maybe> C:\temp\mylog.txt", msg & Environment.NewLine)
End Sub
Of course, a more elaborate scheme could be used, with timestamp, thread ID, severity, whatever.
|
|
|
|
|
Thank you Luc for your pragmatic approach.
Following your basic idea, I had already put a MsgBox after every couple of lines before - so I just had to change them a little bit to get the same result as a log. Unfortunately the result is that the corresponding log lines are just not written (like the msgboxes not shown before), while the log lines of the classes' other methods are written. That's also the basis for my assumption that the events aren't fired at all...? In this special case, the Try... Catch approach didn't seem to make sense, as for the test I removed everything but the log lines from the IDTExtensibility-Members just to see if they are called at all.
Is it possible that I encounter a general problem with the IDTExtensibility2 Interface here? Like written in the above mentiones message, I had experimented with stuff I didn't really understand... Would it be possible that I "destroyed" anything in that interface, so that it doesn't provide the events anymore (e.g. registry setting)? If yes: Would I have to re-install VB Express or can I extract the relevant assembly somehow from the installer package?
Thanks again
Michael
|
|
|
|
|
Hi Michael,
I'm not familiar with the IDTExtensibility2 interface, so I can't comment from experience. I did look a bit at the MSDN documentation and this struck me:
"IDTExtensibility2 contains methods that act as events when the interface is implemented. Visual Studio calls these methods whenever an event that affects an add-in occurs, such as when it is loaded or unloaded, whenever a change is made to it, and so forth." from http://msdn.microsoft.com/en-us/library/extensibility.idtextensibility2(VS.80).aspx[^]
Now how would Visual Studio be involved once your component is ready for use??? I think you'll need to Google some more, maybe find a better example, or a completely different angle on the problem.
Good luck!
|
|
|
|
|
Hi Luc,
thank you for you rapid answer and the link, which I had a quick look on.
Somehow the first sentence "IDTExtensibility2 Interface... Hosts the event notifications that occur to add-ins..." makes me think even more that I might have a problem with the interface itself, since there's obviously no event notification happening.
Probably a re-installation of the interface dll (seems like this msaddndr.dll is part of windows itself) helps - but I guess I'll do that tomorrow. Please send me a short STOP if you think that thought is complete nonsense.
In case you're here in Europe, too I wish you a good night  - and thanks for the mental support anyway
Michael
|
|
|
|
|
You're welcome.
I would not reinstall anything until I was convinced the approach and code are valid (unless there were other reasons to suspect a couple of things of course).
I would research more, and try on another system. I suggest you also try some totally different code that relies on the same parts, maybe something from here[^].
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
