Having written a few webpages for the first time I find that in IE11 on Windows 8.1 they load as expected. However using Firefox 36.0.1 on the same machine most of the pages are loaded scrolled to near the bottom of the page. The pages with some relatively simple comment & reply stuff at the end are the ones that don't load properly. I suspect some of the javascript that opens a form and positions the page for a commenter is the problem. Edit: Now tracked this to creation, then hiding, of a Form for comments which has autofocus required on the first input field. When a user clicks a comment or reply link, my strategy was to append the element .Form to the DIV containing the link and call show on that Form. Can I create the Form in an initially hidden state so the autofocus required doesn't scroll the page down when the page loads?

include wchar.h and try

WCHAR* pData = L"Testing Data";
DWORD dwLength = wcslen(pData);
CFile* pFile = new CFile;
pFile->Open(L"Output.pcm, CFile::modeCreate | CFile::modeReadWrite);
pFile->Write((void*)pData, dwLength * sizeof(WCHAR)); // exception raised here
pFile->Close();

I always use PortMon http://technet.microsoft.com/en-gb/sysinternals/bb896644.aspx[^] to tell me what's really happening with serial problems though of course it may be a USB problem instead. You could use it then have a look for anything when it fails...

I'd guess that any meaningful answer has to be based on the reasons you are using the techniques. Interfaces and a framework in a team environment and managed in a central way can be, as I found, a very good way of managing the code people write and also a extremely useful mechanism that enables the interaction of code written in different languages and by different teams. The ability to have another person write a test based on an interface is also very useful. If you're working by yourself some of the benefits interfaces can bring as just mentioned might be regarded as wasted coding time but perhaps bring benefits that are worth the extra code at design and debug time and also in introducing some discipline. However if you're writing code that you expect others to have to work with in the future you're probably contributing to their being able to understand it relatively quickly - though are probably demanding a fair level of expertise from those future people by your selection of framework etc. Also if your code is part of a generic platform used across applications then using interfaces etc. probably contributes to that. However if its for a specific instance then as you suggest you may be adding generality that's not required. From another perspective i.e. yours, rather than 'the company' are you learning skills and methods that improve your standards - it can get very boring doing the simple things without new approaches. I suppose you've got to way the pros and cons on each technique from say a client, company(over say a N year period) and personal perspective to reach a real conclusion.

I'm not sure about how to simulate one, but I remember using the standard PC keyboard interrupt to trigger events in a C++ (state machine) program assignment I wrote. My lecturer just loaded it onto his PC with all his work on it to try it out and it worked and importantly then returned normal function to the keyboard interrupt I'd used - Interrupt 9. I used a book 'The undocumented PC for information which is/was very good for this sort of stuff. As you mention a USB device, try looking at devices that provide Inputs and Outputs - they often have one or more inputs that can be set to trigger an interrupt when their input state is changed - by say a switch. I've used mostly internal PC I/O cards which can trigger interrupts but also USB devices which provide the same functionality. Serial Port connected devices also have/had this functionality - even if your PC may no longer have a 9 pin serial port.

Have a look at CreateDIBSection http://msdn.microsoft.com/en-us/library/windows/desktop/dd183494(v=vs.85).aspx[^] this can be used to combine BITMPAINFOHEADER data and the actual bits. Though I realise this doesn't actually give you a char pointer it may be something you can use.

It's not an interface that gets created, though an interface will be made available for you to call, its an object that implements the interface that gets created, in this case an object implementing the IMFSourceReader interface. The object created just exposes the interface to the outside world as a known means of using it but when you call a method (or function) on the interface, the call is immediately passed on to the object to carry out the actual work.

Based on sorting out other busses e.g. I2C, CAN I'd recommend: Build in, or use, some logging facility to record what's happening on each chip, even if its only a count or letter stored to show where you're code is going. Use a USB to SPI converter or something you know works to prove each work individually - it's much easier when one end is a 'known' rather than with and 'unknown' at each end of the wire. Read the manuals on the chips and on the SPI bus - I know it's obvious, but chip manuals tend to focus on how the chip works - not on the bus. Get the manual on the bus protocol. Have someone else look at it and show them, OK perhaps you wouldn't be posting here if you could do that but it really helps. I saw someone debug for days without turning power on to a stepper motor he was trying to step. Try and scope the interaction signals, and work through them, after all there should show exactly what's happening: which chip is not responding or signalling as expected. Don't handle just the happy path, handle the error cases as well - e.g. set timeouts and set sone code to log if the time out occurs even if its just to log what the error was.

Having used parallel, serial, usb and all sorts of input/output cards or serial/usb-to-**** add-ons, including building my own, I've not come across anyone trying this. Not saying it can't be done but one function of the 'interfacing' circuits you say are not necessary is to protect your PC/laptop from damage. A relay will require an external power source which if wrongly connected could damage your LAN port and perhaps more. I recommend you get for a USB-to-serial or USB-to-IO converter instead, there's a lot already done with and written about using these.

As you say 'real time' then I guess you'll need some electronics to convert audio to a form suitable for input into your FFT system. I once built the circuitry to utilize an Analog To Digital (A/D) chip to take an external electrical signal, buffer and interface it to a PCs data-bus and then had to write a simple device driver to enable my C++ program to acquire the sampled data and plot it in real time. With a microphone on the front that's the very basics I suppose. I guess if you really mean real time you'll need the equivalent of a sound card or A/D card, i.e. some Audio interface device that you can use to convert the real time audio to your required format so that you can grab it.

My SELECT query works fine when I've got records. Whether there are no records, or not in the result set I get a warning

Warning: mysqli_num_rows() expects parameter 1 to be mysqli_result, null given

I've tested the result agains

FALSE, NULL, null

(both null and NULL seem to be used in examples and the manual)and calling

is_null($result)

but I don't pick it up. Why? I just want to be able to differ between technical failure and return of zero records.

$query = 'SELECT CommentId, ParentId, Subject, Name, DATE_FORMAT(TimeStamp,"%k::%i %d-%m-%Y (GMT)"), Comment FROM commentdata WHERE ArticleId = ' . $ArticleId . ' ORDER BY COALESCE ( ParentId, CommentId)';

    $result = mysqli\_query($connect, $query);
    
    if(TRUE == $result)
    {
        echo 'TRUE returned on query for data: ' . mysqli\_error($connect) . '  

';
}

    if(FALSE == $result)
    {
        echo 'FALSE returned on query for data: ' . mysqli\_error($connect) . '  

';
mysqli_close($connect);
die("Connection closed after FALSE returned on query for data: " . mysqli_error($connect));
}

    if(NULL == $result))
    {
        echo 'NULL returned on query for data: ' . mysqli\_error($connect) . '  

';
mysqli_close($connect);
die("Connection closed after NULL returned on query for data: " . mysqli_error($connect));
}

    if(null == $result))
    {
        echo 'null returned on query for data: ' . mysqli\_error($connect) . '  

';
mysqli_close($connect);
die("Connection closed after null returned on query for data: " . mysqli_error($connect));
}

    if(is\_null($result))
    {
        echo 'NULL returned on query for data: ' . mysqli\_error($connect) . '  

';
mysqli_close($connect);
die("Connection closed after NULL returned on query for data: " . mysqli_error($connect));
}

    /\* determine number of rows in result set \*/
    $rowcount = mysqli\_num\_rows($result);

Sounds like you need to apply two transformations then, one for the player to rotate them and one to rotate the camera position around the same point. That's about the limit of my gl recall I'm afraid.

In a robotics context, at this point I'd ensure I was using a work (player) co-ordinate system rather than a global (the game area) coordinate system or a tool (camera) coordinate system. Is your coordinate system based on the player at this point to make rotation easier? or if not can you switch to one that is? Also are you using a polar coordinate system, to rotate around the player?

Read the MSDN stuff again and found I should have been using GetSysColorBrush(COLOR_MENU); rather then the GetSysColor(COLOR_MENU); I was using which apparently 'returns a cached brush, instead of allocating a new one'. This now does the correct menu background colour. Could explain why GetSysColor(COLOR_MENU); worked yesterday and not today.

Richard, Thanks for the hint, but (as explained below) the problem seems to be with the obtained menu background (white)not being the same colour as the menu (light blue/grey). Thanks anyway.

The problem seems to be that the Menu background as obtained by getting MENUINFO.hbrBack isn't the same colour as the menus. I filled my bitmaps that go on the menus with that colour without any icons to see if it all matched. It doesn't, I can see white squares where the icons go against the light blue/grey of the menu (on Windows 8) That white, as seen behind the drawn bitmaps, is presumably what I was trying to remove. I think I'll take your advice leave it as it is. Thanks.

Using an ImageList to load 16 x 16 bitmaps into a toolbar I've been trying to use the bitmaps from that same ImageList for corresponding menu items but I can't get rid of a whiteness around the images. The main code block code below gives the best I can get. Though I can use a IMAGELISTDRAWPARAMS setting the ilDrawParams.rgbBk = GetSysColor(COLOR_MENU) and using ImageList_DrawIndirect which does get rid of the whiteness though the background is then wrong again if the menu item is highlighted - this also seems to be missing the point when is seems the bitmaps can supposedly be drawn transparently anyway. Any suggestions appreciated.

// Get a menu handle for the one to have an image added to it
HMENU hMenuMain = GetMenu(hWnd); 
HMENU hTestMenu = GetSubMenu(hMenuMain, PORT\_MENU\_ID);

// Load the image i.e. a bitmap 'strip' that is actually a number of bitmaps
HIMAGELIST hImageList = ::ImageList\_LoadImage(hInst, MAKEINTRESOURCE(IDB\_BITMAP1), 16, 0, 
                      RGB(255,0,255), IMAGE\_BITMAP, LR\_SHARED | LR\_LOADTRANSPARENT);

// Get DC for Window client area 
HDC hDCWindow = ::GetDC(hWnd);

// and create a compatibles DC im memory
HDC hDCDest = CreateCompatibleDC(hDCWindow);

// Create a bitmap compatible with the device associated with the DC
HBITMAP hComapatBitmap = CreateCompatibleBitmap(hDCWindow, 16, 16);

// Select the destination bitmap into the DC
HGDIOBJ hOldDestBmp = SelectObject(hDCDest, hComapatBitmap);

// Bitmap is already selected into a screen-compatible device context by the image list
BOOL bDrawn = ImageList\_DrawEx(hImageList, 1, hDCDest, 0, 0, 16, 16, RGB(255, 0, 255), 
                                                    CLR\_NONE , ILD\_TRANSPARENT);

// Select back old object back in retrieving returned drawn bitmap
HBITMAP hRetrievedBitmap = (HBITMAP)::SelectObject(hDCDest, hOldDestBmp);

// as used CreateCompatibleDC(...) must delete it
::DeleteDC(hDCDest);

// as used GetDc must release it
::ReleaseDC(hWnd, hDCWindow);

// Create a structure that describes the change to make to the menu item  
MENUITEMINFO MenuItemInfo;
::SecureZeroMemory(&MenuItemInfo, sizeof(MENUITEMINFO));
MenuItemInfo.cbSize = sizeof(MENUITEMINFO);

MenuItemInfo.fMask = MIIM\_BITMAP;
MenuItemInfo.hbmpItem = hRetrievedBitmap;

// Make the change
::SetMenuItemInfo(hTestMenu, ID\_PORT\_E

I've still got two books on my main bookshelf which puts them a cut above 'the rest', though neither are about software specifically: The Rise of the Player Manager : How professionals manage whilst they work, by Philip Augar & Joy Palmer and the one I wish I'd bought and understood earlier (though I was too busy coding) Successful Project Managers : Leading your team to success by Jeffrey K. Pinto & O.P. Kharabanda I'd make a point of attending any leadership, communication, change, project management etc. courses your employer offers. And if they don't offer them make a point of picking some out and getting them to send you on them. Just chatting to people in the same boat does help, you realise you're not the only one with similar problems. Now points from books or courses often pop back into my mind when certain circumstances occur. The sort of once a month evening meetings local professional associations put on can also help out. Maybe an institution you belong to runs a Mentor scheme? or maybe your organization does? The other thing you need is support from your manager, especially if he or she was in charge before you got promoted. You might get sick of hearing variations of the phrase "XXXXX didn't use to do it this way". If this is a problem, have a conversation and sort out who's in charge of who, and politely put across any points to prevent any undermining of your position. This is bringing it all back, I think I'll go and lie down.

Nothing

Hi, Reading the below answers regarding serial ports made me wonder how safe these (below) calls would be considered. There's no need to pass anything to the constructor as in the reasons I read for using functors, and I only use them in this form because I wrote then when using STL and they're nice one liners really.

hPort = CPortOpener()(hWnd, wszPort);

and

CEditPortSettings()(hWnd, hPort, wszPort);

which use for instance:

class CEditPortSettings
{
public:
CEditPortSettings(void);

long operator()(HWND hWnd, HANDLE hPort, std::wstring szPort)
{
    ...
    return anyerror;    
}